Junio C Hamano [mailto:gits...@pobox.com] wrote:
> We do not gratuitously break existing implementations.  If no conflict is 
> stored
> as higher-stage index entries in an index that has your index extension, no
> existing implementation can read a conflicted index written by your
> implementation and have users resolve conflicts.

I'm not suggesting that anybody stop writing >0 stage entries.

> When a path originally at A is moved to B on only one branch, and there are
> content-level conflicts between the changes made by one branch (while going
> from A to B) and by the other branch (while keeping it at A), we would end up
> having three stages for path B without any trace of path A.  I do not offhand
> know how much it helps to learn A in such a situation in the real life, but 
> we are
> indeed losing information, and I do not have any problem with an extension 
> that
> records in the index the fact that in the two (of the
> three) commits involved in the merge, the path was at A.

What you've described is true only for a certain class of rename conflicts,
for example the rename/edit conflict you've described above.

It's also true if you were to rename some item 'a' to 'b' in both branches.
But when 'b' is sufficiently dissimilar to become a rewrite, then I end up
with a rename of a->b on one side and deleting a and adding b on the other.
The result is a mysterious "added by us" conflict:

100644 e2dd530c9f31550a2b0c90773ccde056929d6d66 2       b

Worse yet is if I don't do the rename in my side, but I just add a new b so
that in theirs I've renamed a to b and in mine I have both a and b.  When I
do the merge, I'm told I have conflicts, except that I don't:

100644 08d4f831774aed5d4c6cb496affefd4020dce40c 0       b

The other branch's b is long gone and exists only as a dirty file in the

> But people have been successfully using existing versions of Git without that
> information to merge branches with renames, and resolving the content-level
> conflicts.

But you aren't afforded the option to resolve content-level conflicts if you
don't know where the conflict came from.  For example, in a rename 1->2
conflict, we dutifully detect that a was renamed to both b and c and fail,
but that fact is never given to the index.  This conflict could be fed into
a merge tool or, better, automerged, with the user only needing to pick a

100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 1       a
100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 3       b
100644 421c9102b8562ad227ba773ab1cf6bbed7b7496d 2       c

I hate to sound like a broken record here, but without some more data in the
index - anywhere, really - any tool that doesn't have the luxury of emitting
data about what happened to stdout certainly can't infer anything about what
happened in the merge.

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