> +# Note: Both x and y got renamed and it'd be nice to detect both, and we do
> +# better with directory rename detection than git did previously, but the
> +# simple rule from section 5 prevents me from handling this as optimally as
> +# we potentially could.
...previously...
> +# Testcase 8e, Both sides rename, one side adds to original directory
> +# Commit O: z/{b,c}
> +# Commit A: y/{b,c}
> +# Commit B: w/{b,c}, z/d
> +#
> +# Possible Resolutions:
> +# Previous git: z/d, CONFLICT(z/b -> y/b vs. w/b), CONFLICT(z/c -> y/c vs.
> w/c)
"Previous git" may be hard to understand when reviewing this code in 2 years.
The future proof term is "git without dir rename detection" or such.
(This is only a small nit, which on its own doesn't require a reroll;
I'll keep reading.)
