Re: Question about git-merge-stupid

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 3, 2008, 17:08 UTC
Message-ID: <alpine.LFD.1.10.0807030947360.18105@woody.linux-foundation.org>
In-Reply-To: <20080703123314.GS4729@genesis.frugalware.org>

On Thu, 3 Jul 2008, Miklos Vajna wrote:

Show 13 quoted lines

> 
> 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.

Show 6 quoted lines

> $ 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