4 ms·

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 us

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.

ethomson 5y ago
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.
harrisi 5y ago
This might help https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github https://docs.github.com/en/repositories/configuring-branches...
- beermonster 5y ago
  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.
avar 5y ago
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?
- ethomson 5y ago
  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/ https://github.blog/2015-12-15-move-fast/
- beermonster 5y ago
  Aha, that’s useful to know. Thanks!

ethomson 5y ago

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.

harrisi 5y ago

This might help https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github https://docs.github.com/en/repositories/configuring-branches...

beermonster 5y ago
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.

avar 5y ago

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?

ethomson 5y ago
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/ https://github.blog/2015-12-15-move-fast/
beermonster 5y ago
Aha, that’s useful to know. Thanks!