RE: Rename conflicts in the index

From: Edward Thomson <ethomson@microsoft.com>
Date: Mar 27, 2013, 17:03 UTC
Message-ID: <A54CE3E330039942B33B670D971F857403A0BA54@TK5EX14MBXC253.redmond.corp.microsoft.com>
In-Reply-To: <7vboa6t14w.fsf@alter.siamese.dyndns.org>

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

Show 5 quoted lines

> 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? Can you suggest some alternate strategy here?

Maybe there's something I'm fundamentally misunderstanding. It seems that at present, git will:

1. Detect rename conflicts when performing a merge (at least,
   git-merge-recursive will, which is the default.)

2. If the rename itself caused a conflict (eg, renamed in one side, added in
   the other) then the merge cannot succeed.

3. The resultant index is written as if renames were not detected, which
   means - at best - records the files that went in to the name conflict
   and git status reports an "added in ours" conflict, which is a pretty
   disappointing conflict.  Often, though, many of the files will not
   exist at higher stage entries, since without rename detection, they
   would have not been conflicts.  At worst, one side is staged, there are
   no conflicts in the index and the user can commit (and thus lose the
   other side.)

Thus it's not like we could add some extension that merely records the names that produced the rename conflicts and point them at the higher stage entries in the index. That would require that they actually be in the index.

Thanks- -ed