Re:Highlights from Git 2.34
by beermonster on Monday November 15, 2021 @05:12PM
(#29233543)
Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.
[ Parent
| on HN ]
GitHub turns off rename detection and turns off recursive base-building when creating merge commits in pull requests. Both of these selections would cause differences in when a merge produces conflicts. This is for backward compatibility with historical mechanisms for merging pull requests, but it seems like something that we might want to revisit.
GitHub (which I'm not affiliated with) does some (all?) of their server-side merging with libgit2, not git itself, although I know they're considering moving to git with the "ort" work. So perhaps it's one of the cases where libgit2's behavior differs?
That's certainly possible, but libgit2 carries an _exhaustive_ test corpus around merge as we aim to be bug-for-bug compatible with git-merge-recursive. This was also proved out by A/B testing the two at scale: https://github.blog/2015-12-15-move-fast/
Re:Highlights from Git 2.34
by beermonster on Monday November 15, 2021 @05:46PM
(#29233941)
Aha, that’s useful to know. Thanks!
This might help https://docs.github.com/en/repositories/configuring-branches...
Re:Highlights from Git 2.34
by beermonster on Monday November 15, 2021 @05:24PM
(#29233686)
That page details squashing and rebasing strategies. It doesn’t talk about different merge points being used in a merge when done on GH compared to when the same merge is performed locally on the command line.