Web lists-archives.com

Re: [PATCH 08/30] directory rename detection: files/directories in the way of some renames

On Mon, Nov 13, 2017 at 4:15 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren <newren@xxxxxxxxx> wrote:
>> +# 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?

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