Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 8, 2005, 21:47 UTC
Message-ID: <7vwtjierrx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051108210211.GA23265@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

> The second reason is that with the fall back list the recursive
> strategy will only be used in the strange corner cases and will thus
> not get nearly the same amount of testing it would get if it was the
> first choice (or directly after the really-trivial merge).

There are two reasons to avoid git-merge choose from more than one strategy.

1. The whole idea that git-merge implements "goodness" metric is
   bogus.  It does not know what merge strategy is good and that
   is the reason it punts and has the user choose his preferred
   strategy.

2. When it is going to loop over more than one strategy, it
   stashes away the current working tree state, so that the
   second and subsequent strategies can begin from a clean slate
   (including local modifications since the current head).  If
   we try only one, there is no such cost involved.

I think the patch I sent out last night to change the recursive as the default strategy and make it overridable from the configuration mechanism would be a better way to give people more exposure to the greatness of recursive while protecting them from potential glitches if any.