On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren <[email protected]> wrote:
> Signed-off-by: Elijah Newren <[email protected]>
> ---
> t/t6043-merge-rename-directories.sh | 137
> ++++++++++++++++++++++++++++++++++++
> 1 file changed, 137 insertions(+)
>
> diff --git a/t/t6043-merge-rename-directories.sh
> b/t/t6043-merge-rename-directories.sh
> index 00811f512a..021513ec00 100755
> --- a/t/t6043-merge-rename-directories.sh
> +++ b/t/t6043-merge-rename-directories.sh
> @@ -513,4 +513,141 @@ test_expect_success '2b-check: Directory split into two
> on one side, with equal
> # messages are handled correctly.
> ###########################################################################
>
> +
> +###########################################################################
> +# SECTION 3: Path in question is the source path for some rename already
> +#
> +# Combining cases from Section 1 and trying to handle them could lead to
> +# directory renaming detection being over-applied. So, this section
> +# provides some good testcases to check that the implementation doesn't go
> +# too far.
> +###########################################################################
> +
> +# Testcase 3a, Avoid implicit rename if involved as source on other side
> +# (Related to testcases 1c and 1f)
> +# Commit A: z/{b,c,d}
> +# Commit B: z/{b,c,d} (no change)
This could also be an unrelated change such as adding w/e?
> +# Commit C: y/{b,c}, x/d
> +# Expected: y/{b,c}, x/d
> +
> +# Testcase 3b, Avoid implicit rename if involved as source on other side
> +# (Related to testcases 5c and 7c, also kind of 1e and 1f)
> +# Commit A: z/{b,c,d}
> +# Commit B: y/{b,c}, x/d
> +# Commit C: z/{b,c}, w/d
> +# Expected: y/{b,c}, CONFLICT:(z/d -> x/d vs. w/d)
> +# NOTE: We're particularly checking that since z/d is already involved as
> +# a source in a file rename on the same side of history, that we
> don't
> +# get it involved in directory rename detection. If it were, we
> might
> +# end up with CONFLICT:(z/d -> y/d vs. x/d vs. w/d), i.e. a
> +# rename/rename/rename(1to3) conflict, which is just weird.
Makes sense.
>
