Re: [PATCH v5 13/34] directory rename detection: tests for handling overwriting untracked files

> --- > t/t6043-merge-rename-directories.sh | 337 > > 1 file changed, 337 insertions(+) > +test_expect_failure '10b-check: Overwrite untracked with dir rename + > delete' ' > + ( > + cd 10b && > + > + git checkout A^0 && > +

Re: [PATCH v5 00/34] Add directory rename detection to git

ld probably work around this by just running grep -q stuff z/c I think I had the asterisks in there because I was thinking in terms of directory rename detection potentially moving the file, but that's probably just overkill. Does the test pass for you with that change? I can test on Monday

Re: [PATCH v5 00/34] Add directory rename detection to git

and then choking on the result. Super weird. I could probably work around this by just running grep -q stuff z/c I think I had the asterisks in there because I was thinking in terms of directory rename detection potentially moving the file, but that's probably just overkill. Does t

Re: [PATCH v5 00/34] Add directory rename detection to git

Am 03.01.2018 um 01:02 schrieb Elijah Newren: > On Wed, Dec 27, 2017 at 8:13 PM, Elijah Newren <new...@gmail.com> wrote: >> This patchset introduces directory rename detection to merge-recursive. See >>https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.

Re: [PATCH v5 04/34] directory rename detection: basic testcases

On Tue, Jan 2, 2018 at 5:18 PM, SZEDER Gábor wrote: > >> --- >> t/t6043-merge-rename-directories.sh | 430 >> > > Many of the new tests added in this patch series perform a lot of checks > running 'test', which has the drawback to fail

Re: [PATCH v5 04/34] directory rename detection: basic testcases

> --- > t/t6043-merge-rename-directories.sh | 430 > Many of the new tests added in this patch series perform a lot of checks running 'test', which has the drawback to fail quietly, leaving us no clue about which one of the several conditions failed and why.

Re: [PATCH v5 00/34] Add directory rename detection to git

On Wed, Dec 27, 2017 at 8:13 PM, Elijah Newren <new...@gmail.com> wrote: > This patchset introduces directory rename detection to merge-recursive. See > https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ > for the first series (including design cons

[PATCH v5 05/34] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- 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 d8ead7c56..acf49d6b4 100755 ---

[PATCH v5 06/34] directory rename detection: testcases to avoid taking detection too far

icit rename if involved as source on other side +# (Related to testcases 5c and 7c, also kind of 1e and 1f) +# Commit O: z/{b,c,d} +# Commit A: y/{b,c}, x/d +# Commit B: 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

[PATCH v5 09/34] directory rename detection: testcases checking which side did the rename

se >actual \ + :0:y/b :3:y/c && + git rev-parse >expect \ + O:z/b O:z/c && + test_cmp expect actual + ) +' + +# Testcase 6b, Same rename done on both sides +# (Related to testcases 6c and 8e) +# Com

[PATCH v5 13/34] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index c731a1b03..7248c3807 100755 ---

[PATCH v5 12/34] directory rename detection: miscellaneous testcases to complete coverage

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

[PATCH v5 00/34] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the first series (including design considerations, etc.), and follow-up series can be found at https://public-inbox.org/git

[PATCH v5 04/34] directory rename detection: basic testcases

e able to handle +### + +# Testcase 1a, Basic directory rename. +# Commit O: z/{b,c} +# Commit A: y/{b,c} +# Commit B: z/{b,c,d,e/f} +# Expected: y/{b,c,d,e/f} + +test_expect_success '1a-setup: Simple directory rename detection' ' + tes

[PATCH v5 11/34] directory rename detection: testcases exploring possibly suboptimal merges

ad non-intuitive or suboptimal behavior for most +# of these cases in git before introducing implicit directory rename +# detection, but it'd be nice if there was a modified ruleset out there +# that handled these cases a bit

[PATCH v5 08/34] directory rename detection: files/directories in the way of some renames

, y/{d,e_2} +# Commit B: y/{b,c,d} +# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning +# NOTE: While directory rename detection is active here causing z/f to +# become y/f, we did not apply this for z/e_1 because that would +# give us an add/add conflict for y/e_1 vs

[PATCH v5 10/34] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 50fb8f41e..cfb53295b 100755 ---

[PATCH v5 32/34] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier pa

[PATCH v5 14/34] directory rename detection: tests for handling overwriting dirty files

ectory-rename-detection and standard +# rename cases. +### + +# Testcase 11a, Avoid losing dirty contents with simple rename +# Commit O: z/{a,b_v1}, +# Commit A: z/{a,c_v1}, and z/c_v1 has uncommitted mods +# Commit B: z/{

[PATCH v5 07/34] directory rename detection: partially renamed directory testcase/discussion

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

Re: [PATCH v4 00/34] Add directory rename detection to git

Ramsay Jones writes: > On 13/12/17 01:06, Junio C Hamano wrote: > >> We may probably want to redirect the output of underlying grep to >> /dev/null in test_i18ngrep to make this kind of misuse easier to >> spot. > > I have test-suite failures on the 'pu' branch for

Re: [PATCH v4 00/34] Add directory rename detection to git

On 13/12/17 01:06, Junio C Hamano wrote: > Elijah Newren <new...@gmail.com> writes: > >> This patchset introduces directory rename detection to merge-recursive. > > The use of negated form of test_i18ngrep in these patches are all > wrong. Because the helper must

Re: [PATCH v4 00/34] Add directory rename detection to git

On Tue, Dec 12, 2017 at 6:01 PM, Junio C Hamano wrote: > OK, it seems that I managed to make this test pass under poison build > (see https://travis-ci.org/git/git/jobs/315658242) > > Please check > https://github.com/git/git/commit/e5c5e24ad91a75b5a70c056fe6c6e3bfb55b56fc >

Re: [PATCH v4 00/34] Add directory rename detection to git

OK, it seems that I managed to make this test pass under poison build (see https://travis-ci.org/git/git/jobs/315658242) Please check https://github.com/git/git/commit/e5c5e24ad91a75b5a70c056fe6c6e3bfb55b56fc and sprinkle its fix to whichever original commits in the series that need fixing.

Re: [PATCH v4 00/34] Add directory rename detection to git

Elijah Newren <new...@gmail.com> writes: > This patchset introduces directory rename detection to merge-recursive. The use of negated form of test_i18ngrep in these patches are all wrong. Because the helper must say "even though the string does not match (does match), th

[PATCH v4 08/34] directory rename detection: files/directories in the way of some renames

,f}, y/{d,e_2} +# Commit B: y/{b,c,d} +# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning +# NOTE: While directory rename detection is active here causing z/f to +# become y/f, we did not apply this for z/e_1 because that would +# give us an add/add conflict for y/e_1 vs

[PATCH v4 07/34] directory rename detection: partially renamed directory testcase/discussion

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

[PATCH v4 09/34] directory rename detection: testcases checking which side did the rename

se >actual \ + :0:y/b :3:y/c && + git rev-parse >expect \ + O:z/b O:z/c && + test_cmp expect actual + ) +' + +# Testcase 6b, Same rename done on both sides +# (Related to testcases 6c and 8e) +# Com

[PATCH v4 32/34] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier pa

[PATCH v4 10/34] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 5db2986de8..2c57a02c6d 100755 ---

[PATCH v4 14/34] directory rename detection: tests for handling overwriting dirty files

enamed-by-directory-rename-detection and standard +# rename cases. +### + +# Testcase 11a, Avoid losing dirty contents with simple rename +# Commit O: z/{a,b_v1}, +# Commit A: z/{a,c_v1}, and z/c_v1 has uncommitted mods +# Commi

[PATCH v4 04/34] directory rename detection: basic testcases

e able to handle +### + +# Testcase 1a, Basic directory rename. +# Commit O: z/{b,c} +# Commit A: y/{b,c} +# Commit B: z/{b,c,d,e/f} +# Expected: y/{b,c,d,e/f} + +test_expect_success '1a-setup: Simple directory rename detection' ' + tes

[PATCH v4 06/34] directory rename detection: testcases to avoid taking detection too far

icit rename if involved as source on other side +# (Related to testcases 5c and 7c, also kind of 1e and 1f) +# Commit O: z/{b,c,d} +# Commit A: y/{b,c}, x/d +# Commit B: 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

[PATCH v4 11/34] directory rename detection: testcases exploring possibly suboptimal merges

ad non-intuitive or suboptimal behavior for most +# of these cases in git before introducing implicit directory rename +# detection, but it'd be nice if there was a modified ruleset out there +# that handled these cases a bit

[PATCH v4 05/34] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- 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 d8ead7c56b..335aa1c145 100755 ---

[PATCH v4 00/34] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the first series (including design considerations, etc.), and follow-up series can be found at https://public-inbox.org/git

[PATCH v4 12/34] directory rename detection: miscellaneous testcases to complete coverage

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

[PATCH v4 13/34] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 42228a60aa..00b0ee7f08 100755 ---

Re: [PATCH v3 00/33] Add directory rename detection to git

On Thu, Nov 23, 2017 at 9:25 PM, Elijah Newren wrote: > On Thu, Nov 23, 2017 at 2:28 PM, Elijah Newren wrote: >> On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote: >>> On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote:

Re: [PATCH v3 00/33] Add directory rename detection to git

On Thu, Nov 23, 2017 at 2:28 PM, Elijah Newren wrote: > On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote: >> On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: >>> >>> >>> merge-recursive.c | 1243 +++- >>>

Re: [PATCH v3 00/33] Add directory rename detection to git

On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote: > On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: >> >> >> merge-recursive.c | 1243 +++- >> merge-recursive.h | 17 + >> t/t3501-revert-cherry-pick.sh

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: > > > merge-recursive.c | 1243 +++- > merge-recursive.h | 17 + > t/t3501-revert-cherry-pick.sh |5 +- > t/t6043-merge-rename-directories.sh | 3821 >

Re: [PATCH v3 00/33] Add directory rename detection to git

AM, Elijah Newren <new...@gmail.com> wrote: >>>> This patchset introduces directory rename detection to merge-recursive; I'm > In my first round of review I only looked over the tests to see if I'd > find the behavior intuitive, I spared the implementation, a

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 5:12 PM, Elijah Newren <new...@gmail.com> wrote: > On Tue, Nov 21, 2017 at 4:42 PM, Stefan Beller <sbel...@google.com> wrote: >> On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren <new...@gmail.com> wrote: >>> This patchset introduces

Re: [PATCH v3 11/33] directory rename detection: testcases exploring possibly suboptimal merges

> +# Note: Both x and y got renamed and it'd be nice to detect both, and we do > +# better with directory rename detection than git did previously, but the > +# simple rule from section 5 prevents me from handling this as optimally as > +# we potentially could. ...previously... >

Re: [PATCH v3 00/33] Add directory rename detection to git

Elijah Newren writes: > Interesting; tbdiff looks cool. Junio hasn't queued this series yet, > but it's easy enough to reconstruct the old one. It does weigh in > pretty heavy, and I'm slighly worried about gmail mangling all the > lines, but I'm going to give it a shot

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 4:42 PM, Stefan Beller <sbel...@google.com> wrote: > On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren <new...@gmail.com> wrote: >> This patchset introduces directory rename detection to merge-recursive; I'm >> resubmitting just a few hours after

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren <new...@gmail.com> wrote: > This patchset introduces directory rename detection to merge-recursive; I'm > resubmitting just a few hours after my PATCHv2 because I didn't know about > the DEVELOPER=1 flag previously, and my co

[PATCH v3 07/33] directory rename detection: partially renamed directory testcase/discussion

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

[PATCH v3 08/33] directory rename detection: files/directories in the way of some renames

,f}, y/{d,e_2} +# Commit B: y/{b,c,d} +# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning +# NOTE: While directory rename detection is active here causing z/f to +# become y/f, we did not apply this for z/e_1 because that would +# give us an add/add conflict for y/e_1 vs

[PATCH v3 14/33] directory rename detection: tests for handling overwriting dirty files

enamed-by-directory-rename-detection and standard +# rename cases. +### + +# Testcase 11a, Avoid losing dirty contents with simple rename +# Commit O: z/{a,b_v1}, +# Commit A: z/{a,c_v1}, and z/c_v1 has uncommitted mods +# Commi

[PATCH v3 12/33] directory rename detection: miscellaneous testcases to complete coverage

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

[PATCH v3 11/33] directory rename detection: testcases exploring possibly suboptimal merges

ad non-intuitive or suboptimal behavior for most +# of these cases in git before introducing implicit directory rename +# detection, but it'd be nice if there was a modified ruleset out there +# that handled these cases a bit

[PATCH v3 09/33] directory rename detection: testcases checking which side did the rename

se >actual \ + :0:y/b :3:y/c && + git rev-parse >expect \ + O:z/b O:z/c && + test_cmp expect actual + ) +' + +# Testcase 6b, Same rename done on both sides +# (Related to testcases 6c and 8e) +# Com

[PATCH v3 05/33] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- 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 d8ead7c56b..335aa1c145 100755 ---

[PATCH v3 31/33] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier pa

[PATCH v3 13/33] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 9e00a26c69..7408c788fc 100755 ---

[PATCH v3 04/33] directory rename detection: basic testcases

e able to handle +### + +# Testcase 1a, Basic directory rename. +# Commit O: z/{b,c} +# Commit A: y/{b,c} +# Commit B: z/{b,c,d,e/f} +# Expected: y/{b,c,d,e/f} + +test_expect_success '1a-setup: Simple directory rename detection' ' + tes

[PATCH v3 06/33] directory rename detection: testcases to avoid taking detection too far

icit rename if involved as source on other side +# (Related to testcases 5c and 7c, also kind of 1e and 1f) +# Commit O: z/{b,c,d} +# Commit A: y/{b,c}, x/d +# Commit B: 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

[PATCH v3 00/33] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive; I'm resubmitting just a few hours after my PATCHv2 because I didn't know about the DEVELOPER=1 flag previously, and my code had a number of warnings/errors. I would have just submitted fixup/squash patches, but when I checked

[PATCH v3 10/33] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 5db2986de8..2c57a02c6d 100755 ---

[RFC PATCH v2 8/9] merge-recursive: accelerate rename detection

and gets the correct merge result. Note that if no rename detection is done, then this will appear to the merge machinery as two files: one that was unmodified on one side of history and deleted on the other (thus the merge should delete it), and one which was newly added on one side of history (thus

[PATCH v2 07/33] directory rename detection: partially renamed directory testcase/discussion

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

[PATCH v2 08/33] directory rename detection: files/directories in the way of some renames

,f}, y/{d,e_2} +# Commit B: y/{b,c,d} +# Expected: z/e_1, y/{b,c,d,e_2,f} + CONFLICT warning +# NOTE: While directory rename detection is active here causing z/f to +# become y/f, we did not apply this for z/e_1 because that would +# give us an add/add conflict for y/e_1 vs

[PATCH v2 00/33] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the previous series, design considerations, etc. Changes since the first series include: * Rebased on latest master (addressing a couple minor

[PATCH v2 14/33] directory rename detection: tests for handling overwriting dirty files

enamed-by-directory-rename-detection and standard +# rename cases. +### + +# Testcase 11a, Avoid losing dirty contents with simple rename +# Commit O: z/{a,b_v1}, +# Commit A: z/{a,c_v1}, and z/c_v1 has uncommitted mods +# Commi

[PATCH v2 09/33] directory rename detection: testcases checking which side did the rename

se >actual \ + :0:y/b :3:y/c && + git rev-parse >expect \ + O:z/b O:z/c && + test_cmp expect actual + ) +' + +# Testcase 6b, Same rename done on both sides +# (Related to testcases 6c and 8e) +# Com

[PATCH v2 12/33] directory rename detection: miscellaneous testcases to complete coverage

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

[PATCH v2 13/33] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 9e00a26c69..7408c788fc 100755 ---

[PATCH v2 05/33] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- 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 d8ead7c56b..335aa1c145 100755 ---

[PATCH v2 10/33] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 5db2986de8..2c57a02c6d 100755 ---

[PATCH v2 11/33] directory rename detection: testcases exploring possibly suboptimal merges

ad non-intuitive or suboptimal behavior for most +# of these cases in git before introducing implicit directory rename +# detection, but it'd be nice if there was a modified ruleset out there +# that handled these cases a bit

[PATCH v2 31/33] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier pa

[PATCH v2 04/33] directory rename detection: basic testcases

e able to handle +### + +# Testcase 1a, Basic directory rename. +# Commit O: z/{b,c} +# Commit A: y/{b,c} +# Commit B: z/{b,c,d,e/f} +# Expected: y/{b,c,d,e/f} + +test_expect_success '1a-setup: Simple directory rename detection' ' + tes

[PATCH v2 06/33] directory rename detection: testcases to avoid taking detection too far

icit rename if involved as source on other side +# (Related to testcases 5c and 7c, also kind of 1e and 1f) +# Commit O: z/{b,c,d} +# Commit A: y/{b,c}, x/d +# Commit B: 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

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 >>

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.

Re: [PATCH 11/30] directory rename detection: testcases exploring possibly suboptimal merges

ries to produce > this output, preferred is what we actually expect. Yes, how about using: "Without dir rename detection:" "Currently expected:" and "Optimal:" ? >> +# Testcase 8b, Dual-directory rename, one into the others' way, with >> conflictin

Re: [PATCH 10/30] directory rename detection: more involved edge/corner testcases

ide that if a source path is renamed on both sides of history, then we'll just ignore both renames for consideration of directory rename detection. The new rule idea would "fix" this testcase to your liking, although now we'd be somewhat inconsistent with the "directory still exis

Re: [PATCH 04/30] directory rename detection: basic testcases

h was the notation commonly used in our codebase since the early days when we needed to call them with single letters. >> +test_expect_success '1a-setup: Simple directory rename detection' ' >> +test_expect_failure '1a-check: Simple directory rename detection' ' > > Thanks for splitting the setu

Re: [PATCH 04/30] directory rename detection: basic testcases

fferently than the first?) Makes sense. >> I'm not following. The "old" and "new" in the filenames were just >> there so a human reading the testcase could easily tell which >> filenames were related and involved in renames. There is no rename >> associ

Re: [PATCH 09/30] directory rename detection: testcases checking which side did the rename

z/{b,c} >> +# Commit B: y/{b,c} >> +# Commit C: y/{b,c}, z/d > > Missing expected state Oops! >> +# Note: If we did directory rename detection here, we'd move z/d into y/, >> +# but C did that rename and still decided to put the file into z/, >>

Re: [PATCH 04/30] directory rename detection: basic testcases

reading the docs above this is clear; I wonder if instead of A, B, C >> a notation of Base, ours, theirs would be easier to understand? > > Sure, that'd be an easy change. > >>> +test_expect_success '1a-setup: Simple directory rename detection' ' >>> +test_exp

Re: [PATCH 08/30] directory rename detection: files/directories in the way of some renames

On Mon, Nov 13, 2017 at 4:15 PM, Stefan Beller <sbel...@google.com> wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren <new...@gmail.com> wrote: >> +# Testcase 5c, Transitive rename would cause >> rename/rename/rename/add/add/add >> +# (Direct

Re: [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far

On Mon, Nov 13, 2017 at 3:25 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> +# Testcase 3a, Avoid implicit rename if involved as source on other side >> +# (Related to testcases 1c and 1f) >> +# Commit A: z/{b,c,d}

Re: [PATCH 04/30] directory rename detection: basic testcases

Base, ours, theirs would be easier to understand? Sure, that'd be an easy change. >> +test_expect_success '1a-setup: Simple directory rename detection' ' >> +test_expect_failure '1a-check: Simple directory rename detection' ' > > Thanks for splitting the setup and the check into tw

Re: [PATCH 10/30] directory rename detection: more involved edge/corner testcases

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > +# In my opinion, testcases that are difficult to understand from this > +# section is due to difficulty in the testcase rather than the directory > +# renaming (similar to how t6042 and t6036 have difficult resolutions

Re: [PATCH 09/30] directory rename detection: testcases checking which side did the rename

6c and 8e) > +# Commit A: z/{b,c} > +# Commit B: y/{b,c} > +# Commit C: y/{b,c}, z/d Missing expected state > +# Note: If we did directory rename detection here, we'd move z/d into y/, > +# but C did that rename and still decided to put the file into z/, > +#

Re: [PATCH 08/30] directory rename detection: files/directories in the way of some renames

> + > +# Testcase 5a, Merge directories, other side adds files to original and > target > +# Commit A: z/{b,c}, y/d > +# Commit B: z/{b,c,e_1,f}, y/{d,e_2} > +# Commit C: y/{b,c,d} > +# Expected: z/e_1, y/

Re: [PATCH 07/30] directory rename detection: partially renamed directory testcase/discussion

ectory; 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 recreat

Re: [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far

it 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 > +#

Re: [PATCH 05/30] directory rename detection: directory splitting testcases

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 125 > > 1 file changed, 125 insertions(+) > > diff --git

Re: [PATCH 04/30] directory rename detection: basic testcases

e to handle > +### > + > +# Testcase 1a, Basic directory rename. > +# Commit A: z/{b,c} > +# Commit B: y/{b,c} > +# Commit C: z/{b,c,d,e/f} (minor thought:) After rereading the docs above t

[PATCH v2 0/4] Fix issues with rename detection limits

This patchset fixes some issues around rename detection limits. Changes since the original submission[1]: * Patches 2 and 3 are swapped in order so as to not temporarily introduce any bugs (even if only cosmetic) * Commit message fixups * Using uint64_t instead of double for holding

Re: [PATCH 00/30] Add directory rename detection to git

From: "Elijah Newren" <new...@gmail.com> : Friday, November 10, 2017 11:26 PM On Fri, Nov 10, 2017 at 2:27 PM, Philip Oakley <philipoak...@iee.org> wrote: From: "Elijah Newren" <new...@gmail.com> In this patchset, I introduce directory rename detectio

Re: [PATCH 00/30] Add directory rename detection to git

On Fri, Nov 10, 2017 at 2:27 PM, Philip Oakley <philipoak...@iee.org> wrote: > From: "Elijah Newren" <new...@gmail.com> >> >> In this patchset, I introduce directory rename detection to >> merge-recursive, >> predominantly so that when files a

Re: [PATCH 00/30] Add directory rename detection to git

From: "Elijah Newren" <new...@gmail.com> [This series is entirely independent of my rename detection limits series. However, I have a separate rename detection performance series that depends on both this series and the rename detection limits series.] In this patchset, I int

[RFC PATCH 8/9] merge-recursive: Accelerate rename detection

and gets the correct merge result. Note that if no rename detection is done, then this will appear to the merge machinery as two files: one that was unmodified on one side of history and deleted on the other (thus the merge should delete it), and one which was newly added on one side of history (thus

[RFC PATCH 0/9] Improve rename detection performance in merge recursive

series, but it'd end up causing lots of merging conflicts, and having this series depend on the other two seemed most logical to me. This patch series tries to improve performance rename detection performance in merge recursive where possible. In particular, I was guided by a specific usecase

[PATCH 13/30] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 314 1 file changed, 314 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index bb179b16c8..7af8962512 100755 ---

<    1   2   3   >