On Thu, 3 Jul 2008, Miklos Vajna wrote: > > I'm trying to understand what is the difference between different merge > strategies. git-merge-stupid is something I failed to understand from > the git history/code/documentation, so I'm asking here. > > 1) From git history: > > It seems git-merge-stupid was created by 2276aa6 when Junio renamed > -resolve to -stupid and let -resolve use read-tree. Actually > > git show 2276aa6:git-merge-stupid.sh > > says -stupid uses read-tree as well. I think -stupid should probably be removed. The history of -stupid is from doing the simple single-tree resolve that git-read-tree can do, but then doing the obvious hack of just trying to pick the base that gives the least number of conflicts. HOWEVER. - in practice, there's seldom any actual point to it. In 99% of all cases, you only have a single merge base anyway. - if you have a workflow that encourages criss-cross merges (which makes the above "in practice" not be true), the common case will be that the merge base doesn't much matter. - Counting conflicts by looking at the numbe of files that conflict is a pretty stupid metric anyway. Yes, it's obvious, and yes, I bet there are cases where it does the right thing, but I also bet there are cases where it does the _wrong_ thing - it might pick a merge base with fewer files conflicting, but with harder conflicts. - the "recursive" merge strategy simply handles things better. There's not really any reason to use a "pick random merge base that happens to give least conflicts", when the recursive strategy does something much more natural. So you shouldn't really compare -stupid to -resolve. You should compare -stupid to -recursive, and the latter is simply much better. > 2) From code: > > It seems -stupid is better than -resolve when there are multiple bases. Maybe. And maybe not. > $ git merge -s resolve c > Trying simple merge. > Merge made by resolve. > > So it seems resolve does not completely fail if there are multiple > bases, either. I think -resolve can handle up to 6 bases, or something like that. After that it should fail with a "I cannot read more than 8 trees" or something (eight being the two trees to be merged, plus the six bases). And with multiple bases, it will already pick the best one on a per-file basis (I think - I should know the threeway merge, but it is pretty confusing code) rather than trying to pick one globally. Not pretty, but it's yet another reason why -stupid is actually stupid, and not worth it. So -stupid in _theory_ can handle cases that -resolve cannot (more than six bases), but (a) that doesn't happen and (b) you'd be better off with -recursive anyway. > 3) From documentation: > > Actually -stupid is missing from Documentation/merge-strategies.txt. I > plan to send a patch to add it, once I understnad what it does. :-) Well, see above. I think there's a reason why -stupid isn't even worth documenting. It might be better off just removed. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
