Re: [PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage
On Wed, Nov 15, 2017 at 12:03 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>
>> +# Testcase 9d, N-fold transitive rename?
>> +# (Related to testcase 9c...and 1c and 7e)
>> +# Commit A: z/a, y/b, x/c, w/d, v/e, u/f
>> +# Commit B: y/{a,b}, w/{c,d}, u/{e,f}
>> +# Commit C: z/{a,t}, x/{b,c}, v/{d,e}, u/f
>> +# Expected:
>> +#
>> +# NOTE: z/ -> y/ (in commit B)
>> +# y/ -> x/ (in commit C)
>> +# x/ -> w/ (in commit B)
>> +# w/ -> v/ (in commit C)
>> +# v/ -> u/ (in commit B)
>> +# So, if we add a file to z, say z/t, where should it end up? In u?
>> +# What if there's another file or directory named 't' in one of the
>> +# intervening directories and/or in u itself? Also, shouldn't the
>> +# same logic that places 't' in u/ also move ALL other files to u/?
>> +# What if there are file or directory conflicts in any of them? If
>> +# we attempted to do N-way (N-fold? N-ary? N-uple?) transitive
>> renames
>> +# like this, would the user have any hope of understanding any
>> +# conflicts or how their working tree ended up? I think not, so I'm
>> +# ruling out N-ary transitive renames for N>1.
>> +#
>> +# Therefore our expected result is:
>> +# z/t, y/a, x/b, w/c, u/d, u/e, u/f
>> +# The reason that v/d DOES get transitively renamed to u/d is that u/
>> isn't
>> +# renamed somewhere. A slightly sub-optimal result, but it uses fairly
>> +# simple rules that are consistent with what we need for all the other
>> +# testcases and simplifies things for the user.
>
> Does the merge order matter here?
No.
> If B and C were swapped, applying the same logic presented in the NOTE,
> one could argue that we expect:
>
> z/t y/a x/b w/c v/d v/e u/f
>
> I can make a strong point for y/a here, but the v/{d,e} also seem to deviate.
I don't understand; I thought my argument as presented was agnostic of
direction. Perhaps I have an unstated assumption I'm not realizing or
something; could you explain how my logic above could lead to this
conclusion?
Also, let me try a different tack to see if it's clearer than the
above argument I made. Looking at each path:
* z/t from commit C does not get renamed to y/t despite B's rename of
z/ -> y/ because C renamed y/ elsewhere.
* z/a from commit A was renamed to y/a in commit B. We do not
transitively rename further from y/a to x/a (despite C's rename of y/
to x/) because B renamed x/ elsewhere.
* y/b from commit A was renamed to x/b in commit C. We do not
transitively rename further from x/b to w/b (despite B's rename of x/
to w/) because C renamed w/ elsewhere.
* x/c from commit A was renamed to w/c in commit B. We do not
transitively rename further from w/c to v/c (despite C's rename from
w/ to v/) because B renamed v/ elsewhere.
* w/d from commit A was renamed to v/d in commit C. We DO
transitively rename from v/d to u/d because of B's rename of v/ to u/
and because C did not rename u/ to somewhere else.
(And, to complete the list, e and f are simple: v/e is renamed to u/e
in commit B, and there's no directory name on u on either side, so
there's no special logic needed at all. u/f is even simpler; there's
no renames or directory renames or anything affecting it.)
>> +# Testcase 9e, N-to-1 whammo
>> +# (Related to testcase 9c...and 1c and 7e)
>> +# Commit A: dir1/{a,b}, dir2/{d,e}, dir3/{g,h}, dirN/{j,k}
>> +# Commit B: dir1/{a,b,c,yo}, dir2/{d,e,f,yo}, dir3/{g,h,i,yo},
>> dirN/{j,k,l,yo}
>> +# Commit C: combined/{a,b,d,e,g,h,j,k}
>> +# Expected: combined/{a,b,c,d,e,f,g,h,i,j,k,l}, CONFLICT(Nto1) warnings,
>> +# dir1/yo, dir2/yo, dir3/yo, dirN/yo
>
> Very neat!
:-)
>> +# Testcase 9f, Renamed directory that only contained immediate subdirs
>> +# (Related to testcases 1e & 9g)
>> +# Commit A: goal/{a,b}/$more_files
>> +# Commit B: priority/{a,b}/$more_files
>> +# Commit C: goal/{a,b}/$more_files, goal/c
>> +# Expected: priority/{a,b}/$more_files, priority/c
>
>> +# Testcase 9g, Renamed directory that only contained immediate subdirs,
>> immediate subdirs renamed
>> +# (Related to testcases 1e & 9f)
>> +# Commit A: goal/{a,b}/$more_files
>> +# Commit B: priority/{alpha,bravo}/$more_files
>> +# Commit C: goal/{a,b}/$more_files, goal/c
>> +# Expected: priority/{alpha,bravo}/$more_files, priority/c
>
> and if C also added goal/a/another_file, we'd expect it to
> become priority/alpha/another_file.
Yep! I thought that was covered enough by other tests, but do you
feel I should add that to this testcase?
> What happens in moving dir hierarchies?
>
> A: root/node1/{leaf1, leaf2}, root/node2/{leaf3, leaf4}
> B: "Move node2 one layer down into node1"
> root/node1/{leaf1, leaf2, node2/{leaf3, leaf4}}
> C: "Add more leaves"
> root/node1/{leaf1, leaf2, leaf5}, root/node2/{leaf3, leaf4, leaf6}
Works just fine; similar to testcase 9a. Do you feel this o
Re: [PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> +###
> +# SECTION 9: Other testcases
> +#
> +# I came up with the testcases in the first eight sections before coding up
> +# the implementation. The testcases in this section were mostly ones I
> +# thought of while coding/debugging, and which I was too lazy to insert
> +# into the previous sections because I didn't want to re-label with all the
> +# testcase references. :-)
This might also be commit message material, as it describes the workflow,
not the 'misc' aspect of these test cases.
> +###
> +
> +# Testcase 9a, Inner renamed directory within outer renamed directory
> +# (Related to testcase 1f)
> +# Commit A: z/{b,c,d/{e,f,g}}
> +# Commit B: y/{b,c}, x/w/{e,f,g}
> +# Commit C: z/{b,c,d/{e,f,g,h},i}
> +# Expected: y/{b,c,i}, x/w/{e,f,g,h}
> +# NOTE: The only reason this one is interesting is because when a directory
> +# is split into multiple other directories, we determine by the
> weight
> +# of which one had the most paths going to it. A naive
> implementation
> +# of that could take the new file in commit C at z/i to x/w/i or x/i.
Makes sense.
> +# Testcase 9b, Transitive rename with content merge
> +# (Related to testcase 1c)
> +# Commit A: z/{b,c}, x/d_1
> +# Commit B: y/{b,c}, x/d_2
> +# Commit C: z/{b,c,d_3}
> +# Expected: y/{b,c,d_merged}
Makes sense.
> +# Testcase 9c, Doubly transitive rename?
> +# (Related to testcase 1c, 7e, and 9d)
> +# Commit A: z/{b,c}, x/{d,e},w/f
> +# Commit B: y/{b,c}, x/{d,e,f,g}
> +# Commit C: z/{b,c,d,e}, w/f
> +# Expected: y/{b,c,d,e}, x/{f,g}
> +#
> +# NOTE: x/f and x/g may be slightly confusing here. The rename from w/f to
> +# x/f is clear. Let's look beyond that. Here's the logic:
> +#Commit C renamed x/ -> z/
> +#Commit B renamed z/ -> y/
> +# So, we could possibly further rename x/f to z/f to y/f, a doubly
> +# transient rename. However, where does it end? We can chain these
> +# indefinitely (see testcase 9d). What if there is a D/F conflict
> +# at z/f/ or y/f/? Or just another file conflict at one of those
> +# paths? In the case of an N-long chain of transient renamings,
> +# where do we "abort" the rename at? Can the user make sense of
> +# the resulting conflict and resolve it?
> +#
> +# To avoid this confusion I use the simple rule that if the other
> side
> +# of history did a directory rename to a path that your side renamed
> +# away, then ignore that particular rename from the other side of
> +# history for any implicit directory renames.
This is repeated in the rule of section 9 below.
Makes sense.
> +# Testcase 9d, N-fold transitive rename?
> +# (Related to testcase 9c...and 1c and 7e)
> +# Commit A: z/a, y/b, x/c, w/d, v/e, u/f
> +# Commit B: y/{a,b}, w/{c,d}, u/{e,f}
> +# Commit C: z/{a,t}, x/{b,c}, v/{d,e}, u/f
> +# Expected:
> +#
> +# NOTE: z/ -> y/ (in commit B)
> +# y/ -> x/ (in commit C)
> +# x/ -> w/ (in commit B)
> +# w/ -> v/ (in commit C)
> +# v/ -> u/ (in commit B)
> +# So, if we add a file to z, say z/t, where should it end up? In u?
> +# What if there's another file or directory named 't' in one of the
> +# intervening directories and/or in u itself? Also, shouldn't the
> +# same logic that places 't' in u/ also move ALL other files to u/?
> +# What if there are file or directory conflicts in any of them? If
> +# we attempted to do N-way (N-fold? N-ary? N-uple?) transitive
> renames
> +# like this, would the user have any hope of understanding any
> +# conflicts or how their working tree ended up? I think not, so I'm
> +# ruling out N-ary transitive renames for N>1.
> +#
> +# Therefore our expected result is:
> +# z/t, y/a, x/b, w/c, u/d, u/e, u/f
> +# The reason that v/d DOES get transitively renamed to u/d is that u/ isn't
> +# renamed somewhere. A slightly sub-optimal result, but it uses fairly
> +# simple rules that are consistent with what we need for all the other
> +# testcases and simplifies things for the user.
Does the merge order matter here?
If B and C were swapped, applying the same logic presented in the NOTE,
one could argue that we expect:
z/t y/a x/b w/c v/d v/e u/f
I can make a strong point for y/a here, but the v/{d,e} also seem to deviate.
> +# Testcase 9e, N-to-1 whammo
> +# (Related to testcase 9c...and 1c and 7e)
> +# Commit A: dir1/{a,b}, dir2/{d,e}, dir3/{g,h}, dirN/{j,k}
> +# Commit B: dir1/{a,b,c,yo}, dir2/{d,e,f,yo}, dir3/{g,h,i,yo},
> dirN/{j,k,l,yo}
> +# Commit C: combined/{a,b,d,e,g,h,j,k}
> +# Expected: combined/{a,b
[PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 505
1 file changed, 505 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index bdfd943c88..bb179b16c8 100755
--- a/t/t6043-merge-rename-directories.sh
+++ b/t/t6043-merge-rename-directories.sh
@@ -265,6 +265,7 @@ test_expect_failure '1d-check: Directory renames cause a
rename/rename(2to1) con
'
# Testcase 1e, Renamed directory, with all filenames being renamed too
+# (Related to testcases 9f & 9g)
# Commit A: z/{oldb,oldc}
# Commit B: y/{newb,newc}
# Commit C: z/{oldb,oldc,d}
@@ -2054,4 +2055,508 @@ test_expect_failure '8e-check: Both sides rename, one
side adds to original dire
test_i18ngrep CONFLICT.*rename/rename.*z/b.*y/b.*w/b out
'
+###
+# SECTION 9: Other testcases
+#
+# I came up with the testcases in the first eight sections before coding up
+# the implementation. The testcases in this section were mostly ones I
+# thought of while coding/debugging, and which I was too lazy to insert
+# into the previous sections because I didn't want to re-label with all the
+# testcase references. :-)
+###
+
+# Testcase 9a, Inner renamed directory within outer renamed directory
+# (Related to testcase 1f)
+# Commit A: z/{b,c,d/{e,f,g}}
+# Commit B: y/{b,c}, x/w/{e,f,g}
+# Commit C: z/{b,c,d/{e,f,g,h},i}
+# Expected: y/{b,c,i}, x/w/{e,f,g,h}
+# NOTE: The only reason this one is interesting is because when a directory
+# is split into multiple other directories, we determine by the weight
+# of which one had the most paths going to it. A naive implementation
+# of that could take the new file in commit C at z/i to x/w/i or x/i.
+
+test_expect_success '9a-setup: Inner renamed directory within outer renamed
directory' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ mkdir -p z/d &&
+ echo b >z/b &&
+ echo c >z/c &&
+ echo e >z/d/e &&
+ echo f >z/d/f &&
+ echo g >z/d/g &&
+ git add z &&
+ test_tick &&
+ git commit -m "A" &&
+
+ git branch A &&
+ git branch B &&
+ git branch C &&
+
+ git checkout B &&
+ mkdir x &&
+ git mv z/d x/w &&
+ git mv z y &&
+ test_tick &&
+ git commit -m "B" &&
+
+ git checkout C &&
+ echo h >z/d/h &&
+ echo i >z/i &&
+ git add z &&
+ test_tick &&
+ git commit -m "C"
+'
+
+test_expect_failure '9a-check: Inner renamed directory within outer renamed
directory' '
+ git checkout B^0 &&
+
+ git merge -s recursive C^0 &&
+
+ test 7 -eq $(git ls-files -s | wc -l) &&
+ test 0 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test $(git rev-parse HEAD:y/b) = $(git rev-parse A:z/b) &&
+ test $(git rev-parse HEAD:y/c) = $(git rev-parse A:z/c) &&
+ test $(git rev-parse HEAD:y/i) = $(git rev-parse C:z/i) &&
+
+ test $(git rev-parse HEAD:x/w/e) = $(git rev-parse A:z/d/e) &&
+ test $(git rev-parse HEAD:x/w/f) = $(git rev-parse A:z/d/f) &&
+ test $(git rev-parse HEAD:x/w/g) = $(git rev-parse A:z/d/g) &&
+ test $(git rev-parse HEAD:x/w/h) = $(git rev-parse C:z/d/h)
+'
+
+# Testcase 9b, Transitive rename with content merge
+# (Related to testcase 1c)
+# Commit A: z/{b,c}, x/d_1
+# Commit B: y/{b,c}, x/d_2
+# Commit C: z/{b,c,d_3}
+# Expected: y/{b,c,d_merged}
+
+test_expect_success '9b-setup: Transitive rename with content merge' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ mkdir z &&
+ echo b >z/b &&
+ echo c >z/c &&
+ mkdir x &&
+ test_seq 1 10 >x/d &&
+ git add z x &&
+ test_tick &&
+ git commit -m "A" &&
+
+ git branch A &&
+ git branch B &&
+ git branch C &&
+
+ git checkout B &&
+ git mv z y &&
+ test_seq 1 11 >x/d &&
+ git add x/d &&
+ test_tick &&
+ git commit -m "B" &&
+
+ git checkout C &&
+ test_seq 0 10 >x/d &&
+ git mv x/d z/d &&
+ git add z/d &&
+ test_tick &&
+ git commit -m "C"
+'
+
+test_expect_failure '9b-check: Transitive rename with content merge' '
+ git checkout B^0 &&
+
+ git merge -s recursive C^0 &&
+
+ test 3 -eq $(git ls-files -s | wc -l) &&
+
+ test $(git rev-parse HEAD:y/b) = $(git rev-parse A:z/b) &&
+ test $(git rev-parse HEAD:y/c) = $(git rev-parse A:z/c) &&
+ test_must_fail git rev-parse HEAD:x/d &&
+ test_must_fail git rev-parse HEAD:z/d &&
+ test ! -f z/d &&
+
+ test $(git rev-parse HEAD:y/d) != $(git rev-parse A:x/d) &&
+ test $(git rev-parse HEAD:y/d
