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 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 -- 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
