Re: [PATCH 07/30] directory rename detection: partially renamed directory testcase/discussion
From: Stefan Beller <hidden>
Date: 2017-11-14 00:07:12
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 | 100 ++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+)diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 021513ec00..ec054b210a 100755 --- a/t/t6043-merge-rename-directories.sh +++ b/t/t6043-merge-rename-directories.sh@@ -650,4 +650,104 @@ test_expect_success '3b-check: Avoid implicit rename if involved as source on cu # of a rename on either side of a merge. ########################################################################### + +########################################################################### +# SECTION 4: Partially renamed directory; still exists on both sides of merge +# +# What if we were to attempt to do directory rename detection when someone +# "mostly" moved a directory but still left some files around, or, +# equivalently, fully renamed a directory in one commmit and then recreated +# that directory in a later commit adding some new files and then tried to +# merge? +# +# It's hard to divine user intent in these cases, because you can make an +# argument that, depending on the intermediate history of the side being +# merged, that some users will want files in that directory to +# automatically be detected and renamed, while users with a different +# intermediate history wouldn't want that rename to happen. +# +# I think that it is best to simply not have directory rename detection +# apply to such cases. My reasoning for this is four-fold: (1) it's +# easiest for users in general to figure out what happened if we don't +# apply directory rename detection in any such case, (2) it's an easy rule +# to explain ["We don't do directory rename detection if the directory +# still exists on both sides of the merge"], (3) we can get some hairy +# edge/corner cases that would be really confusing and possibly not even +# representable in the index if we were to even try, and [related to 3] (4) +# attempting to resolve this issue of divining user intent by examining +# intermediate history goes against the spirit of three-way merges and is a +# path towards crazy corner cases that are far more complex than what we're +# already dealing with.
This last paragraph ("I think") sounds like part of a commit message,
rather than
a note inside a testing script. Not sure if I recommend moving this
text into the
commit message.
+# This section contains a test for this partially-renamed-directory case.
+###########################################################################
+
+# Testcase 4a, Directory split, with original directory still present
+# (Related to testcase 1f)
+# Commit A: z/{b,c,d,e}
+# Commit B: y/{b,c,d}, z/e
+# Commit C: z/{b,c,d,e,f}
+# Expected: y/{b,c,d}, z/{e,f}
+# NOTE: Even though most files from z moved to y, we don't want f to follow.Makes sense.
+########################################################################### +# Rules suggested by section 4: +# +# Directory-rename-detection should be turned off for any directories (as +# a source for renames) that exist on both sides of the merge. (The "as +# a source for renames" clarification is due to cases like 1c where +# the target directory exists on both sides and we do want the rename +# detection.) But, sadly, see testcase 8b.
Looking forward for that test case.