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*
