Re: [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far
From: Stefan Beller <hidden>
Date: 2017-11-13 23:25:45
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Signed-off-by: Elijah Newren <redacted> --- 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.