Elijah Newren <newren@xxxxxxxxx> writes: > +# criss-cross with rename/rename(1to2)/modify followed by > +# rename/rename(2to1)/modify: > +# > +# B D > +# o---o > +# / \ / \ > +# A o X ? F > +# \ / \ / > +# o---o > +# C E > +# > +# Commit A: new file: a > +# Commit B: rename a->b, modifying by adding a line > +# Commit C: rename a->c > +# Commit D: merge B&C, resolving conflict by keeping contents in newname > +# Commit E: merge B&C, resolving conflict similar to D but adding another line > +# > +# There is a conflict merging B & C, but one of filename not of file > +# content. Whoever created D and E chose specific resolutions for that > +# conflict resolution. Now, since: (1) there is no content conflict > +# merging B & C, (2) D does not modify that merged content further, and (3) > +# both D & E resolve the name conflict in the same way, the modification to > +# newname in E should not cause any conflicts when it is merged with D. > +# (Note that this can be accomplished by having the virtual merge base have > +# the merged contents of b and c stored in a file named a, which seems like > +# the most logical choice anyway.) Interesting. I do not necessarily agree with the choice "a", but it feels sound to say "B and C do not agree what the final pathname should be, but we know this content was derived from the common A:a so we use one path whose name is arbitrary in the virtual merge base X between D and E" and then further let the rename detection to notice that that arbitrary path gets renamed between X-D to "newname" and X-E also to "newname" to resolve it as both sides renaming it to the same new name. It is akin to what we do at the content level, i.e. "B and C do not agree what the final contents should be, so we leave the conflict marker but that may cancel out at the final merge stage". > +test_expect_failure 'handle rename/rename(1to2)/modify followed by what looks like rename/rename(2to1)/modify' ' > + git checkout D^0 && > + > + git merge -s recursive E^0 && > + > + test 1 -eq $(git ls-files -s | wc -l) && > + test 0 -eq $(git ls-files -u | wc -l) && > + test 0 -eq $(git ls-files -o | wc -l) && > + > + test 8 -eq $(wc -l < newname) Be a bit more explicit with what you are actually testing. Are you expecting that the index has a single stage #0 entry for "newname" whose contents are the same as E? > +' > > test_done -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html