Junio C Hamano [mailto:gits...@pobox.com] wrote:
> Edward Thomson <ethom...@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
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.
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