Junio C Hamano [mailto:gits...@pobox.com] wrote:
> We do not gratuitously break existing implementations. If no conflict is
> 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
> 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
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