logoalt Hacker News

sameenkarimtoday at 12:07 AM2 repliesview on HN

Yes, we handle this both in the CLI and server using git rebase --onto

  git rebase --onto <new_commit_sha_generated_by_squash> <original_commit_sha_from_tip_of_merged_branch> <branch_name>
So for ex in this scenario:

  PR1: main <- A, B              (branch1)
  PR2: main <- A, B, C, D        (branch2)
  PR3: main <- A, B, C, D, E, F  (branch3)
When PR 1 and 2 are squash merged, main now looks like:

  S1 (squash of A+B), S2 (squash of C+D)
Then we run the following:

  git rebase --onto S2 D branch3
Which rewrites branch3 to:

  S1, S2, E, F
This operation moves the unique commits from the unmerged branch and replays them on top of the newly squashed commits on the base branch, avoiding any merge conflicts.

Replies

jd3today at 3:55 PM

We dealt with this headache for 7+ years at my former employer. Thanks so much for this.

puelocesartoday at 7:57 AM

That’s how I’ve been working for years now. Does anyone know how this gh stacks work internally? Does it do the same thing under the hood?

I’m conflicted about it, seems like a good convenience, but I wouldn’t want my team to get dependent on an exclusive feature of a single provider

show 1 reply