RE: Rename conflicts in the index

From: Edward Thomson <ethomson@microsoft.com>
Date: Mar 13, 2013, 20:44 UTC
Message-ID: <A54CE3E330039942B33B670D971F85740399654B@TK5EX14MBXC252.redmond.corp.microsoft.com>
In-Reply-To: <7va9q72n1u.fsf@alter.siamese.dyndns.org>

Junio C Hamano [mailto:gitster@pobox.com] wrote:

Show 7 quoted lines

> I do not offhand see anything particularly stupid; a new optional index extension
> section CACHE_EXT_RENAME_CONFLICT might be a good addition.
> 
> Is "one side moves A to B while the other side moves it to C" the only case, or is
> it just an example?  Off the top of my head, "one side moves A to x while the
> other side moves B to x/y" would also be something we would want to know.  I
> am sure there are other cases that need to be considered.

Yes, that was just an example. Certainly I was intending that all conflicts that arose from renames would end up here since one can't really reason why the merge tool created a conflict by looking at the index alone - even knowing the merge tool's similarity algorithms, this would be awfully expensive to piece back together, even if the index did contain non-zero stage entries for all the items that were involved in the conflicts.

That said, my rather naive initial thought was that we could repeat *all* conflicts in this area. This would give tools that knew how to understand this the ability to go to a single place for conflict data, rather than producing some merge of high-stage entries that comprise non-rename conflicts and data from the rename conflict area for rename conflicts.

Thanks- -ed