On Tue, Mar 13, 2018 at 3:56 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Elijah Newren wrote: > >> However, my question here about what to write to the working tree for >> a rename/rename(2to1) conflict in one particular corner case still >> remains. Should a two-way merge be performed even if it may result in >> nested sets of conflict markers, or is that a sufficiently bad outcome >> for the user that it's the one case we do want to write colliding >> files out to different temporary paths? > > Nested conflict markers only happen in the conflictstyle=diff3 case, I > would think.
Currently, yes. To be clear, though, this change would make it possible even when there is no recursive merge being done and when conflictstyle=merge. > merge-recursive writes them already. I've often wished that it would > use a union merge strategy when building the common ancestor to avoid > the nested conflicts that rerere doesn't understand. But anyway, > that's an orthogonal issue: in the rename/rename context, it should be > fine to write nested conflict markers since that's consistent with > what merge-recursive already does. Cool, sounds like we're now all on the same page. Someone in the future might hate us if they use conflictstyle=diff3, and have a recursive merge, and have a rename/rename(2to1) conflict in the virtual merge base with nested conflicts, and that resulting file is also involved in a separate rename/rename(2to1) conflict in the outer merge that has its own nested conflicts; we'd have up to four levels of nested conflicts. But for now, I'm going to write that off as a crazy thought (or dismiss it as nigh impossible to reason about regardless of what we did to help them) and just proceed ahead. :-)
