From: Elijah Newren <newren@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage
Date: Thu, 16 Nov 2017 13:17:52 -0800 [thread overview]
Message-ID: <CABPp-BF5=vKUhGGrzkV=FZ_4Syuer+WEZT36kvEHbaxtHVdTsQ@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kb13gGJ6V9d08evHKLvTdTQwcp8VAyzi36BnGn-m5pTXQ@mail.gmail.com>
On Wed, Nov 15, 2017 at 12:03 PM, Stefan Beller <sbeller@google.com> wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren <newren@gmail.com> 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: <see NOTE first>
>> +#
>> +# 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 one is
different enough to add to the testsuite? I'm happy to do so.
> Or chaining putting things in one another:
> (Same A)
> B: "Move node2 one layer down into node1"
> root/node1/{leaf1, leaf2, node2/{leaf3, leaf4}}
> C: "Move node1 one layer down into node2"
> root/node2/{leaf3, leaf4, node1/{leaf1, leaf2}}
>
> Just food for thought.
That's evil. I mean, it's a brilliant testcase designed to really
mess things up. I'm not entirely sure what the right answer should
be, but I am confident saying my current implementation handles it
wrong. I'm digging into why.
next prev parent reply other threads:[~2017-11-16 21:18 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 19:05 [PATCH 00/30] Add directory rename detection to git Elijah Newren
2017-11-10 19:05 ` [PATCH 01/30] Tighten and correct a few testcases for merging and cherry-picking Elijah Newren
2017-11-13 19:32 ` Stefan Beller
2017-11-10 19:05 ` [PATCH 02/30] merge-recursive: Fix logic ordering issue Elijah Newren
2017-11-13 19:48 ` Stefan Beller
2017-11-13 22:04 ` Elijah Newren
2017-11-13 22:12 ` Stefan Beller
2017-11-13 23:39 ` Elijah Newren
2017-11-13 23:46 ` Stefan Beller
2017-11-10 19:05 ` [PATCH 03/30] merge-recursive: Add explanation for src_entry and dst_entry Elijah Newren
2017-11-13 21:06 ` Stefan Beller
2017-11-13 22:57 ` Elijah Newren
2017-11-13 23:11 ` Stefan Beller
2017-11-14 1:26 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 04/30] directory rename detection: basic testcases Elijah Newren
2017-11-13 22:04 ` Stefan Beller
2017-11-14 0:57 ` Elijah Newren
2017-11-14 1:21 ` Stefan Beller
2017-11-14 1:40 ` Elijah Newren
2017-11-14 2:03 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 05/30] directory rename detection: directory splitting testcases Elijah Newren
2017-11-13 23:20 ` Stefan Beller
2017-11-10 19:05 ` [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far Elijah Newren
2017-11-13 23:25 ` Stefan Beller
2017-11-14 1:02 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 07/30] directory rename detection: partially renamed directory testcase/discussion Elijah Newren
2017-11-14 0:07 ` Stefan Beller
2017-11-10 19:05 ` [PATCH 08/30] directory rename detection: files/directories in the way of some renames Elijah Newren
2017-11-14 0:15 ` Stefan Beller
2017-11-14 1:19 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 09/30] directory rename detection: testcases checking which side did the rename Elijah Newren
2017-11-14 0:25 ` Stefan Beller
2017-11-14 1:30 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 10/30] directory rename detection: more involved edge/corner testcases Elijah Newren
2017-11-14 0:42 ` Stefan Beller
2017-11-14 21:11 ` Elijah Newren
2017-11-14 22:47 ` Stefan Beller
2017-11-10 19:05 ` [PATCH 11/30] directory rename detection: testcases exploring possibly suboptimal merges Elijah Newren
2017-11-14 20:33 ` Stefan Beller
2017-11-14 21:42 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 12/30] directory rename detection: miscellaneous testcases to complete coverage Elijah Newren
2017-11-15 20:03 ` Stefan Beller
2017-11-16 21:17 ` Elijah Newren [this message]
2017-11-10 19:05 ` [PATCH 13/30] directory rename detection: tests for handling overwriting untracked files Elijah Newren
2017-11-10 19:05 ` [PATCH 14/30] directory rename detection: tests for handling overwriting dirty files Elijah Newren
2017-11-10 19:05 ` [PATCH 15/30] merge-recursive: Move the get_renames() function Elijah Newren
2017-11-14 4:46 ` Junio C Hamano
2017-11-14 17:41 ` Elijah Newren
2017-11-15 1:20 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 16/30] merge-recursive: Introduce new functions to handle rename logic Elijah Newren
2017-11-14 4:56 ` Junio C Hamano
2017-11-14 5:14 ` Junio C Hamano
2017-11-14 18:24 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 17/30] merge-recursive: Fix leaks of allocated renames and diff_filepairs Elijah Newren
2017-11-14 4:58 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 18/30] merge-recursive: Make !o->detect_rename codepath more obvious Elijah Newren
2017-11-10 19:05 ` [PATCH 19/30] merge-recursive: Split out code for determining diff_filepairs Elijah Newren
2017-11-14 5:20 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 20/30] merge-recursive: Add a new hashmap for storing directory renames Elijah Newren
2017-11-10 19:05 ` [PATCH 21/30] merge-recursive: Add get_directory_renames() Elijah Newren
2017-11-14 5:30 ` Junio C Hamano
2017-11-14 18:38 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 22/30] merge-recursive: Check for directory level conflicts Elijah Newren
2017-11-10 19:05 ` [PATCH 23/30] merge-recursive: Add a new hashmap for storing file collisions Elijah Newren
2017-11-10 19:05 ` [PATCH 24/30] merge-recursive: Add computation of collisions due to dir rename & merging Elijah Newren
2018-06-10 10:56 ` René Scharfe
2018-06-10 11:03 ` René Scharfe
2018-06-10 20:44 ` Jeff King
2018-06-11 15:03 ` Elijah Newren
2018-06-14 17:36 ` Junio C Hamano
2017-11-10 19:05 ` [PATCH 25/30] merge-recursive: Check for file level conflicts then get new name Elijah Newren
2017-11-10 19:05 ` [PATCH 26/30] merge-recursive: When comparing files, don't include trees Elijah Newren
2017-11-10 19:05 ` [PATCH 27/30] merge-recursive: Apply necessary modifications for directory renames Elijah Newren
2017-11-15 20:23 ` Stefan Beller
2017-11-16 3:54 ` Elijah Newren
2017-11-10 19:05 ` [PATCH 28/30] merge-recursive: Avoid clobbering untracked files with " Elijah Newren
2017-11-10 19:05 ` [RFC PATCH 29/30] merge-recursive: Fix overwriting dirty files involved in renames Elijah Newren
2017-11-10 19:05 ` [PATCH 30/30] merge-recursive: Fix remaining directory rename + dirty overwrite cases Elijah Newren
2017-11-10 22:27 ` [PATCH 00/30] Add directory rename detection to git Philip Oakley
2017-11-10 23:26 ` Elijah Newren
2017-11-13 15:04 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABPp-BF5=vKUhGGrzkV=FZ_4Syuer+WEZT36kvEHbaxtHVdTsQ@mail.gmail.com' \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).