On 6/26/2021 1:05 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@xxxxxxxxx>
>
> Directory rename detection can cause transitive renames, e.g. if the two
> different sides of history each do one half of:
> A/file -> B/file
> B/ -> C/
> then directory rename detection transitively renames to give us C/file.
> Since the default for merge.directoryRenames is conflict, this results
> in an error message saying it is unclear whether the file should be
> placed at B/file or C/file.
>
> What if C/ is A/, though?
This case seems interesting, but somehow missing from the test cases
below. Each of those cases include renaming up or down the directory
hierarchy instead of doing a sideways rename.
> +# Testcase 12i, Directory rename causes rename-to-self
> +# Commit O: source/{subdir/foo, bar, baz_1}
> +# Commit A: source/{foo, bar, baz_1}
> +# Commit B: source/{subdir/{foo, bar}, baz_2}
> +# Expected: source/{foo, bar, baz_2}, with conflicts on
> +# source/bar vs. source/subdir/bar
This test goes deeper.
> +# Testcase 12j, Directory rename to root causes rename-to-self
> +# Commit O: {subdir/foo, bar, baz_1}
> +# Commit A: {foo, bar, baz_1}
> +# Commit B: {subdir/{foo, bar}, baz_2}
> +# Expected: {foo, bar, baz_2}, with conflicts on bar vs. subdir/bar
This test goes higher.
Does the problematic case not hit when going out to the side, such
as "with conflicts on subdir/bar vs otherdir/bar"?
If so, then _maybe_ the commit message could indicate this is an
omission on purpose. If not, then maybe a third test should be
added?
Thanks,
-Stolee
