Re: [RFH] Merge driver

Daniel Barkalow [off-list ref] writes:

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

quoted

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

On Fri, 9 Sep 2005, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

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.

Ah, okay. I hadn't realized that resolve used -u for that call to 
read-tree. You're entirely right.

	-Daniel
*This .sig left intentionally blank*