Re:Highlights from Git 2.34
by IlGrigiore on Monday November 15, 2021 @04:16PM
(#29232888)
They have shipped a new default merging strategy, 'ort', that is supposedly better than the previous default strategy at resolving this kind of issue. You should probably try and see if it makes any difference.
My understanding was that `merge -sort` is generally faster and has less buggy edge cases, but does it resolve conflict any differently than -s recursive ?
That's correct, there may be some very obscure edge cases where it has different behavior (known merge-recursive bugs), but in the general case if you've got UX problems with rebase or merge it won't help.
Unless that UX problem is helped by it being much, much faster, but that's usually only going to be matter for larger repositories.
For example when I try to bring an old feature branch forward, or when I have two private branches with a common history that I've touched on one side and want rebase to apply my history change onto the other branch, I'm often made to resolve a lot more conflict that seems necessary.
There are scripts like git-imerge that give some much nicer conflicts. imerge may not be perfect, but I think it shows there's room for a more clever algorithm.
I'd happily have a git rebase --full-resolver --wuauctl option that consumes a mysteriously large amounts of CPU time, if it saves me some manual conflict resolution =)