Re: [RFH] Merge driver

From: Junio C Hamano <junkio@cox.net>
Date: Sep 9, 2005, 16:43 UTC
Message-ID: <7vy866jio4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0509091151520.23242@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 9 quoted lines

> I'd actually been thinking it would just go into the the "resolve" driver, 
> with that going back to before it chose among merge-base outputs and just 
> sending the whole list to read-tree.
>
> This is no good: the current 'resolve' can generate wrong results and 
> report that it worked cleanly, while 'multibase' would report a conflict 
> because it isn't ignoring a real problem. My primary goal in doing the 
> multibase version wasn't to produce more clean merges; it was to produce 
> fewer clean-but-wrong merges.

True. Before 'git-merge' hits the "master" branch I should remove 'git-merge-resolve' from the strategies list (or rename 'git-merge-multibase' to it). I have them separately only because I wanted to be able to see how differently they perform by saying:

    git merge -s resolve blah...
    git merge -s multibase blah...

Show 7 quoted lines

>> *1* Fredrik, I have been wondering if we can just say that lack
>> of '-u' flag implies '-i'.  Is there a good reason that
>> 'git-read-tree -m O A B' without '-u' should care if working
>> tree is up to date for the paths involved?
>
> It tries to make sure that there is room to put stuff for resolving a 
> conflict without messing with modified files in the directory.

I agree it can be used that way, but nobody seems to use it for that purpose as far as I can tell hence my earlier comment. But let's leave the door open by having them as independent options.