RE: Rename conflicts in the index

From: Edward Thomson <ethomson@microsoft.com>
Date: Apr 1, 2013, 16:14 UTC
Message-ID: <A54CE3E330039942B33B670D971F857403A0E20C@TK5EX14MBXC253.redmond.corp.microsoft.com>
In-Reply-To: <7v38vgmxty.fsf@alter.siamese.dyndns.org>

Junio C Hamano [mailto:gister@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.

Show 6 quoted lines

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

Show 5 quoted lines

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

Thanks-

-ed