Junio C Hamano [mailto:gis...@pobox.com] wrote:
> As long as
> the format will be backward compatible to allow existing users use existing
> 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
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