From: Junio C Hamano Date: Tue, 08 Nov 2005 00:13:38 GMT Subject: Re: Comments on recursive merge.. Message-ID: <7vll00ov2l.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20051107225807.GA10937@c165.ib.student.liu.se> Fredrik Kuivinen writes: > 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.