Re: Question about git-merge-stupid

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