Re: [PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage

> +###########################################################################
> +# SECTION 9: Other testcases
> +#
> +# I came up with the testcases in the first eight sections before coding up
> +# the implementation.  The testcases in this section were mostly ones I
> +# thought of while coding/debugging, and which I was too lazy to insert
> +# into the previous sections because I didn't want to re-label with all the
> +# testcase references.  :-)

> +###########################################################################
> +
> +# Testcase 9a, Inner renamed directory within outer renamed directory
> +#   (Related to testcase 1f)
> +#   Commit A: z/{b,c,d/{e,f,g}}
> +#   Commit B: y/{b,c}, x/w/{e,f,g}
> +#   Commit C: z/{b,c,d/{e,f,g,h},i}
> +#   Expected: y/{b,c,i}, x/w/{e,f,g,h}
> +#   NOTE: The only reason this one is interesting is because when a directory
> +#         is split into multiple other directories, we determine by the weight
> +#         of which one had the most paths going to it.  A naive implementation
> +#         of that could take the new file in commit C at z/i to x/w/i or x/i.

> +# Testcase 9b, Transitive rename with content merge
> +#   (Related to testcase 1c)
> +#   Commit A: z/{b,c},   x/d_1
> +#   Commit B: y/{b,c},   x/d_2
> +#   Commit C: z/{b,c,d_3}
> +#   Expected: y/{b,c,d_merged}

> +# Testcase 9c, Doubly transitive rename?
> +#   (Related to testcase 1c, 7e, and 9d)
> +#   Commit A: z/{b,c},     x/{d,e},    w/f
> +#   Commit B: y/{b,c},     x/{d,e,f,g}
> +#   Commit C: z/{b,c,d,e},             w/f
> +#   Expected: y/{b,c,d,e}, x/{f,g}
> +#
> +#   NOTE: x/f and x/g may be slightly confusing here.  The rename from w/f to
> +#         x/f is clear.  Let's look beyond that.  Here's the logic:
> +#            Commit C renamed x/ -> z/
> +#            Commit B renamed z/ -> y/
> +#         So, we could possibly further rename x/f to z/f to y/f, a doubly
> +#         transient rename.  However, where does it end?  We can chain these
> +#         indefinitely (see testcase 9d).  What if there is a D/F conflict
> +#         at z/f/ or y/f/?  Or just another file conflict at one of those
> +#         paths?  In the case of an N-long chain of transient renamings,
> +#         where do we "abort" the rename at?  Can the user make sense of
> +#         the resulting conflict and resolve it?
> +#
> +#         To avoid this confusion I use the simple rule that if the other side
> +#         of history did a directory rename to a path that your side renamed
> +#         away, then ignore that particular rename from the other side of
> +#         history for any implicit directory renames.

> +# Testcase 9d, N-fold transitive rename?
> +#   (Related to testcase 9c...and 1c and 7e)
> +#   Commit A: z/a, y/b, x/c, w/d, v/e, u/f
> +#   Commit B:  y/{a,b},  w/{c,d},  u/{e,f}
> +#   Commit C: z/{a,t}, x/{b,c}, v/{d,e}, u/f
> +#   Expected: <see NOTE first>
> +#
> +#   NOTE: z/ -> y/ (in commit B)
> +#         y/ -> x/ (in commit C)
> +#         x/ -> w/ (in commit B)
> +#         w/ -> v/ (in commit C)
> +#         v/ -> u/ (in commit B)
> +#         So, if we add a file to z, say z/t, where should it end up?  In u?
> +#         What if there's another file or directory named 't' in one of the
> +#         intervening directories and/or in u itself?  Also, shouldn't the
> +#         same logic that places 't' in u/ also move ALL other files to u/?
> +#         What if there are file or directory conflicts in any of them?  If
> +#         we attempted to do N-way (N-fold? N-ary? N-uple?) transitive renames
> +#         like this, would the user have any hope of understanding any
> +#         conflicts or how their working tree ended up?  I think not, so I'm
> +#         ruling out N-ary transitive renames for N>1.
> +#
> +#   Therefore our expected result is:
> +#     z/t, y/a, x/b, w/c, u/d, u/e, u/f
> +#   The reason that v/d DOES get transitively renamed to u/d is that u/ isn't
> +#   renamed somewhere.  A slightly sub-optimal result, but it uses fairly
> +#   simple rules that are consistent with what we need for all the other
> +#   testcases and simplifies things for the user.

> +# Testcase 9e, N-to-1 whammo
> +#   (Related to testcase 9c...and 1c and 7e)
> +#   Commit A: dir1/{a,b}, dir2/{d,e}, dir3/{g,h}, dirN/{j,k}
> +#   Commit B: dir1/{a,b,c,yo}, dir2/{d,e,f,yo}, dir3/{g,h,i,yo}, dirN/{j,k,l,yo}
> +#   Commit C: combined/{a,b,d,e,g,h,j,k}
> +#   Expected: combined/{a,b,c,d,e,f,g,h,i,j,k,l}, CONFLICT(Nto1) warnings,
> +#             dir1/yo, dir2/yo, dir3/yo, dirN/yo

> +# Testcase 9f, Renamed directory that only contained immediate subdirs
> +#   (Related to testcases 1e & 9g)
> +#   Commit A: goal/{a,b}/$more_files
> +#   Commit B: priority/{a,b}/$more_files
> +#   Commit C: goal/{a,b}/$more_files, goal/c
> +#   Expected: priority/{a,b}/$more_files, priority/c

> +# Testcase 9g, Renamed directory that only contained immediate subdirs, immediate subdirs renamed
> +#   (Related to testcases 1e & 9f)
> +#   Commit A: goal/{a,b}/$more_files
> +#   Commit B: priority/{alpha,bravo}/$more_files
> +#   Commit C: goal/{a,b}/$more_files, goal/c
> +#   Expected: priority/{alpha,bravo}/$more_files, priority/c

> +# Rules suggested by section 9:
> +#
> +#   If the other side of history did a directory rename to a path that your
> +#   side renamed away, then ignore that particular rename from the other
> +#   side of history for any implicit directory renames.