Re: Comments on recursive merge..

From: Junio C Hamano <junkio@cox.net>
Date: Nov 8, 2005, 00:13 UTC
Message-ID: <7vll00ov2l.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051107225807.GA10937@c165.ib.student.liu.se>

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

Show 11 quoted lines

> On Mon, Nov 07, 2005 at 08:48:06AM -0800, Linus Torvalds wrote:
>> 
>> Guys,
>> 
>>   I just hit my first real rename conflict, and very timidly tried the 
>> "recursive" strategy in the hopes that I wouldn't need to do things by 
>> hand.
>> 
>> It resolved things beautifully. Good job. 
>
> I'm glad that it worked.

This is the first time I see you pleased by something in git that was done without very close supervision from you. All the credits for this one goes to Fredrik, of course, but it is a small victory for me as the maintainer as well, and I am very happy about it.

>> ..., I'd almost suggest making "recursive" the default. I'm a
>> bit nervous about it, but knowing how it works would probably
>> put most of that to rest.

Another thing to consider is if it is fast enough for everyday trivial merges.

In any case, I've been thinking about teaching git-merge to look into .git/config to make it overridable which strategy to use by default. This would eliminate the hardcoded 'resolve for two-head, octopus for more' rule from git-pull. Then we could ship git-merge with the default rule of 'recursive for two-head, octopus for more', and if it turns out to be premature, you can update your config file to use resolve for two-head case while we sort things out. That way, recursive would get wider test coverage, and people who really need a working merge this minute can choose to run resolve in emergency without specifying '-s resolve' on the command line of 'git pull' every time.