Re: Rename conflicts in the index

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 27, 2013, 17:34 UTC
Message-ID: <7vk3osn3vs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <A54CE3E330039942B33B670D971F857403A0BA54@TK5EX14MBXC253.redmond.corp.microsoft.com>

Edward Thomson <ethomson@microsoft.com> writes:

Show 8 quoted lines

> Junio C Hamano [mailto:gitster@pobox.com] wrote:
>> Edward Thomson <ethomson@microsoft.com> writes:
>> > I would propose that this not simply track rename conflicts, but all
>> > conflicts.
>> 
>> That is a no starter.
>
> So.  Can you explain to me why this would be a non starter?

At least two, IIRC.  One is the consequence of the other.

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.

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.

But people have been successfully using existing versions of Git without that information to merge branches with renames, and resolving the content-level conflicts. Your tool that _additionally_ records "This path that currently has three stages for B was at A in the common ancestor (i.e. stage #1) and that branch (either stage #2 or stage #3)" does not _have_ _to_ break these users by removing the three stages for B from the main index.

Also we do not duplicate information unnecessarily. Nowhere in the above "we have been losing the fact that two of the three had the contents we have at path B in the resulting unmerged index at path A, and that information might be useful as well", there is a reason to write another copy of mode or SHA-1 for any of the three variants.

As I said, you do not live in the world where you are writing something like Git from scratch. Perhaps you do, but then the result will not be Git and we wouldn't be discussing that system on this mailing list.