4 ms·

Once you start doing serialized PRs then doing squash merges increases your chance of a nightmare. For example you have PR 1 and PR 2 (based on 1). Squash merg

Once you start doing serialized PRs then doing squash merges increases your chance of a nightmare. For example you have PR 1 and PR 2 (based on 1). Squash merge PR 1 into main. But while 2 is under review someone merges in 3 into main and you need to bring it into 2 to resolve some conflicts. You’re now hosed because the changes done in 1 are now present TWICE. First in 1’s commit, and also in the squash commit. Now you’re resolving all of 1’s changes as merge conflicts. This may sound like a contrived examples but it has happened to me EVERY time I’ve worked somewhere that demands squash commits. And this is one of the reasons I hate squash commits. “Makes the history prettier” vs “Rewriting the actual commit history”. Telling the truth > pretty.

IshKebab 3y ago
Ah I think where you're going wrong is trying to merge master into PR 2. Instead you should just rebase PR 2 on top of master. Git will automatically figure out that PR 1 has been merged and drop it. If it doesn't for some reason you can just do an interactive rebase. Git history isn't "the truth" until it's shared. There's absolutely no issue rewriting history history for your own edits that nobody else is using yet. You do that every time you press undo!
- atq2119 3y ago
  > Git will automatically figure out that PR 1 has been merged and drop it. Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on (the branch of) PR2. When cherrypicking the commits corresponding to PR1 during the rebase, the merge algorithm will notice that the change is already there and notify you of the empty commit if the change is completely identical. But if it isn't, that falls down. It's still not too difficult to recover, but it's annoying.
- IshKebab 3y ago
  > Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on PR2. Did you try it? It does still work. Git will detect that the changes are identical and drop it, even if the commit hash is different.

IshKebab 3y ago

Ah I think where you're going wrong is trying to merge master into PR 2. Instead you should just rebase PR 2 on top of master. Git will automatically figure out that PR 1 has been merged and drop it. If it doesn't for some reason you can just do an interactive rebase. Git history isn't "the truth" until it's shared. There's absolutely no issue rewriting history history for your own edits that nobody else is using yet. You do that every time you press undo!

atq2119 3y ago
> Git will automatically figure out that PR 1 has been merged and drop it. Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on (the branch of) PR2. When cherrypicking the commits corresponding to PR1 during the rebase, the merge algorithm will notice that the change is already there and notify you of the empty commit if the change is completely identical. But if it isn't, that falls down. It's still not too difficult to recover, but it's annoying.
IshKebab 3y ago
> Unfortunately, that part doesn't work if you let GitHub do a squash, because then the commit on main has no corresponding commit on PR2. Did you try it? It does still work. Git will detect that the changes are identical and drop it, even if the commit hash is different.