On Mon, Nov 13, 2017 at 4:15 PM, Stefan Beller [off-list ref] wrote:

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren [off-list ref] wrote:

quoted

+# Testcase 5c, Transitive rename would cause rename/rename/rename/add/add/add
+#   (Directory rename detection would result in transitive rename vs.
+#    rename/rename(1to2) and turn it into a rename/rename(1to3).  Further,
+#    rename paths conflict with separate adds on the other side)
+#   (Related to testcases 3b and 7c)
+#   Commit A: z/{b,c}, x/d_1
+#   Commit B: y/{b,c,d_2}, w/d_1
+#   Commit C: z/{b,c,d_1,e}, w/d_3, y/d_4
+#   Expected: A mess, but only a rename/rename(1to2)/add/add mess.  Use the
+#             presence of y/d_4 in C to avoid doing transitive rename of
+#             x/d_1 -> z/d_1 -> y/d_1, so that the only paths we have at
+#             y/d are y/d_2 and y/d_4.  We still do the move from z/e to y/e,
+#             though, because it doesn't have anything in the way.

Missing the expected state, only the explanation is given.

Yeah...it seemed so ugly to try to write down.  As a possible
sidenote, this testcase was actually guided by the final test of
t6042, which is messy enough, but directory rename detection provides
a little extra freedom to get a higher order conflict and make things
a bit messier.  It felt like it was a case where just leaving the
expectation in code in the 5c-check was just easier and maybe even
clearer.  Should I add a comment to that effect, or would you really
just prefer to see it spelled out?

quoted

 falling
+#   back to old handling.  But, sadly, see testcases 8a and 8b.

You seem to be hinting at these all the time.

I think there were just multiple angles at which to approach those
testcases.  *shrug*