Daniel Barkalow <[EMAIL PROTECTED]> 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...
>> *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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
