Junio C Hamano [mailto:gis...@pobox.com] wrote:
> As long as
> the format will be backward compatible to allow existing users use existing 
> tools
> to deal with cases the existing tools can handle, then that is OK.  I didn't 
> get that
> impression which is where my "non starter" came from.

I see now.  Thank you for the clarification.  I apologize if I was not clear
about this; indeed, the duplication of data in my proposed extension was
specifically to avoid any compatibility problems amongst clients.

In particular, when we have a rename in ours, edit in theirs conflict, we
store the conflict at the new (ours) path.  If, for example, I rename a->b
in my branch and merge a branch that edits a:

mode hash 1 b
mode hash 2 b
mode hash 3 b

This prohibits us from storing anything else in the theirs side at that
path, so if I were to have added b in their branch in addition to modifying
b, I cannot record it.

I was assuming that any change to this behavior would be a breaking one,
which is where the new section came from.

>  * Path A may have only stage #1, while path B and C has only stage
>    #2 and stage #3 (the user would have to notice these three
>    correspond to each other, and resolve manually).
>    You would want to annotate "B at stage #2 seems to have been at A
>    in the original" (similarly for C#3) if you choose to do so.

If we're going to make changes to the way conflicts are recorded in the
main index, then I would prefer this approach.  It is unambiguous and all
data about all sides are recorded, including the names that items had in
their respective branches.

I would think that this might be a burden on current tools, however.
Now if I rename a->b my just my branch, my conflict will be recorded as:

mode hash 1 a
mode hash 2 b
mode hash 3 a

And current git-status will not look at any rename annotations to know
how to report this.

However, maybe this is not as big a problem as I'm concerned it would be.

>  * You can choose to favor "our" choice, and have path B with three
>    stages (if we guessed wrong and the user wants to move it to C,
>    the user can resolve and then "git mv" the path).

I think this approach suffers from the drawback that the current approach
has, wherein this conflicts when they had path B, also, as noted above.

I think that if you were to put both B and C with all three stages, this
would be problematic for the same reason.

> *1* Instead of a three-way merge that inspects only the endpoints,
>     you might get a better rename trail if you looked at the
>     histories of both branches.  It would be a lot more expensive
>     than the simple three-way, but burning CPU cycles is better than
>     burning human neurons.

For the record, I like this approach very much.  It's not something that
libgit2 will be able to tackle in the near future; we're in a sort of
walk-before-you-can-run situation with merge at the moment, as you can
probably see.  But any improvement that avoids burning neurons is a
valuable one.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to