From: Elijah Newren <newren@gmail.com>
To: <git@vger.kernel.org>
Cc: <gitster@pobox.com>, <stolee@gmail.com>,
Elijah Newren <newren@gmail.com>
Subject: [PATCH v4 00/10] Improve path collision conflict resolutions
Date: Fri, 2 Nov 2018 11:53:08 -0700 [thread overview]
Message-ID: <20181102185317.31015-1-newren@gmail.com> (raw)
In-Reply-To: <20181019193111.12051-1-newren@gmail.com>
This series depends on en/merge-cleanup-more and is built on that
series. (It merges cleanly to master, next, and pu -- well, as long
as v3 of this series is excluded from pu, that is).
This series makes all the "file collision" conflict types be handled
consistently; making them all behave like add/add (as suggested by
Jonathan[1] and Junio[2]). These types are:
* add/add
* rename/add
* rename/rename(2to1)
* each rename/add piece of a rename/rename(1to2)/add[/add] conflict
[1] https://public-inbox.org/git/20180312213521.GB58506@aiede.svl.corp.google.com/
[2] https://public-inbox.org/git/CAPc5daVu8vv9RdGON8JiXEO3ycDVqQ38ySzZc-cpo+AQcAKXjA@mail.gmail.com
Changes since v3:
* Fixed test names to be surrounded by single quotes instead of double
quotes, as suggested by Derrick.
* Two more (RFC) patches add a couple testcases to cover previously
uncovered code, as pointed out by Derrick and his test coverage report.
* Full range-diff below.
Major question:
* You'll note that I edited the last two patches to mark them as RFC.
To be honest, I'm not sure what to do with these. They improve code
coverage of new code, but the same gaps existed in the old code;
they only show up in the coverage-diff because I essentially moved
code around to a new improved function. Since the new code doesn't
really add new abilities but rather just shifts the handling of
these conflicts to a common function, they shouldn't need any more
testcases than previously and modifying the existing patches thus
feels slightly misleading. That line of thought leads me to believe
that perhaps putting them in a separate combined patch of their own
with a decent commit message is the right way to go. On the other
hand, squashing them to the commits they're marked as fixups for
shows which logical part of the code the tests are related to, which
seems like a good thing. So what's the right way to handle these?
1: 1be9e213db ! 1: 0fa67d6109 t6036, t6042: testcases for rename collision of already conflicting files
@@ -51,7 +51,7 @@
+# conflict markers. This is a pretty weird corner case, but we just want
+# to ensure that we handle it as well as practical.
+
-+test_expect_success "setup nested conflicts" '
++test_expect_success 'setup nested conflicts' '
+ test_create_repo nested_conflicts &&
+ (
+ cd nested_conflicts &&
@@ -130,7 +130,7 @@
+ )
+'
+
-+test_expect_failure "check nested conflicts" '
++test_expect_failure 'check nested conflicts' '
+ (
+ cd nested_conflicts &&
+
@@ -241,7 +241,7 @@
+#
+# So, we have four different conflicting files that all end up at path
+# 'three'.
-+test_expect_success "setup nested conflicts from rename/rename(2to1)" '
++test_expect_success 'setup nested conflicts from rename/rename(2to1)' '
+ test_create_repo nested_conflicts_from_rename_rename &&
+ (
+ cd nested_conflicts_from_rename_rename &&
@@ -294,7 +294,7 @@
+ )
+'
+
-+test_expect_failure "check nested conflicts from rename/rename(2to1)" '
++test_expect_failure 'check nested conflicts from rename/rename(2to1)' '
+ (
+ cd nested_conflicts_from_rename_rename &&
+
2: d3356ff525 ! 2: 9f5f0105d0 merge-recursive: increase marker length with depth of recursion
@@ -179,7 +179,7 @@
+# nested conflict markers from X2 in the base version -- that means we
+# have three levels of conflict markers. Can we distinguish all three?
+
-+test_expect_success "setup virtual merge base with nested conflicts" '
++test_expect_success 'setup virtual merge base with nested conflicts' '
+ test_create_repo virtual_merge_base_has_nested_conflicts &&
+ (
+ cd virtual_merge_base_has_nested_conflicts &&
@@ -241,7 +241,7 @@
+ )
+'
+
-+test_expect_success "check virtual merge base with nested conflicts" '
++test_expect_success 'check virtual merge base with nested conflicts' '
+ (
+ cd virtual_merge_base_has_nested_conflicts &&
+
3: aa68e3d675 = 3: 5922c40fa7 merge-recursive: new function for better colliding conflict resolutions
4: f046ba6362 = 4: dcf88dd363 merge-recursive: fix rename/add conflict handling
5: 37742bdefd ! 5: 1d11288be4 merge-recursive: improve handling for rename/rename(2to1) conflicts
@@ -209,8 +209,8 @@
)
'
--test_expect_failure "check nested conflicts" '
-+test_expect_success "check nested conflicts" '
+-test_expect_failure 'check nested conflicts' '
++test_expect_success 'check nested conflicts' '
(
cd nested_conflicts &&
@@ -290,8 +290,8 @@
)
'
--test_expect_failure "check nested conflicts from rename/rename(2to1)" '
-+test_expect_success "check nested conflicts from rename/rename(2to1)" '
+-test_expect_failure 'check nested conflicts from rename/rename(2to1)' '
++test_expect_success 'check nested conflicts from rename/rename(2to1)' '
(
cd nested_conflicts_from_rename_rename &&
6: 776dff8bc4 = 6: 1fad3428a4 merge-recursive: use handle_file_collision for add/add conflicts
7: 45940724d5 = 7: e7ac0d894e merge-recursive: improve rename/rename(1to2)/add[/add] handling
-: ---------- > 8: 9328f66ed1 fixup! merge-recursive: fix rename/add conflict handling
-: ---------- > 9: d061509573 fixup! merge-recursive: improve rename/rename(1to2)/add[/add] handling
Elijah Newren (10):
Add testcases for consistency in file collision conflict handling
t6036, t6042: testcases for rename collision of already conflicting
files
merge-recursive: increase marker length with depth of recursion
merge-recursive: new function for better colliding conflict
resolutions
merge-recursive: fix rename/add conflict handling
merge-recursive: improve handling for rename/rename(2to1) conflicts
merge-recursive: use handle_file_collision for add/add conflicts
merge-recursive: improve rename/rename(1to2)/add[/add] handling
fixup! merge-recursive: fix rename/add conflict handling
fixup! merge-recursive: improve rename/rename(1to2)/add[/add] handling
ll-merge.c | 4 +-
ll-merge.h | 1 +
merge-recursive.c | 528 ++++++++++++++++-----------
t/t6036-recursive-corner-cases.sh | 430 +++++++++++++++++++++-
t/t6042-merge-rename-corner-cases.sh | 333 ++++++++++++++++-
t/t6043-merge-rename-directories.sh | 144 +++++---
6 files changed, 1148 insertions(+), 292 deletions(-)
--
2.19.0.232.gd14c2061fc
next prev parent reply other threads:[~2018-11-02 18:53 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-14 2:05 [RFC PATCH v2 0/7] Improve path collision conflict resolutions Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 1/7] Add testcases for consistency in file collision conflict handling Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 2/7] t6036, t6042: testcases for rename collision of already conflicting files Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 3/7] merge-recursive: new function for better colliding conflict resolutions Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 4/7] merge-recursive: fix rename/add conflict handling Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 5/7] merge-recursive: improve handling for rename/rename(2to1) conflicts Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 6/7] merge-recursive: use handle_file_collision for add/add conflicts Elijah Newren
2018-10-14 2:05 ` [RFC PATCH v2 7/7] merge-recursive: improve rename/rename(1to2)/add[/add] handling Elijah Newren
2018-10-19 19:31 ` [PATCH v3 0/8] Improve path collision conflict resolutions Elijah Newren
2018-10-19 19:31 ` [PATCH v3 1/8] Add testcases for consistency in file collision conflict handling Elijah Newren
2018-10-19 19:31 ` [PATCH v3 2/8] t6036, t6042: testcases for rename collision of already conflicting files Elijah Newren
2018-10-31 14:01 ` Derrick Stolee
2018-11-01 6:57 ` Elijah Newren
2018-10-19 19:31 ` [PATCH v3 3/8] merge-recursive: increase marker length with depth of recursion Elijah Newren
2018-10-19 19:31 ` [PATCH v3 4/8] merge-recursive: new function for better colliding conflict resolutions Elijah Newren
2018-10-31 13:53 ` Derrick Stolee
2018-10-31 13:57 ` Derrick Stolee
2018-11-01 6:56 ` Elijah Newren
2018-10-19 19:31 ` [PATCH v3 5/8] merge-recursive: fix rename/add conflict handling Elijah Newren
2018-10-19 19:31 ` [PATCH v3 6/8] merge-recursive: improve handling for rename/rename(2to1) conflicts Elijah Newren
2018-10-19 19:31 ` [PATCH v3 7/8] merge-recursive: use handle_file_collision for add/add conflicts Elijah Newren
2018-10-19 19:31 ` [PATCH v3 8/8] merge-recursive: improve rename/rename(1to2)/add[/add] handling Elijah Newren
2018-10-31 15:08 ` Derrick Stolee
2018-11-01 7:01 ` Elijah Newren
2018-11-02 17:27 ` Elijah Newren
2018-11-02 17:30 ` Derrick Stolee
2018-11-02 18:53 ` Elijah Newren [this message]
2018-11-02 18:53 ` [PATCH v4 01/10] Add testcases for consistency in file collision conflict handling Elijah Newren
2018-11-02 18:53 ` [PATCH v4 02/10] t6036, t6042: testcases for rename collision of already conflicting files Elijah Newren
2018-11-02 18:53 ` [PATCH v4 03/10] merge-recursive: increase marker length with depth of recursion Elijah Newren
2018-11-02 18:53 ` [PATCH v4 04/10] merge-recursive: new function for better colliding conflict resolutions Elijah Newren
2018-11-02 18:53 ` [PATCH v4 05/10] merge-recursive: fix rename/add conflict handling Elijah Newren
2018-11-02 18:53 ` [PATCH v4 06/10] merge-recursive: improve handling for rename/rename(2to1) conflicts Elijah Newren
2018-11-02 18:53 ` [PATCH v4 07/10] merge-recursive: use handle_file_collision for add/add conflicts Elijah Newren
2018-11-02 18:53 ` [PATCH v4 08/10] merge-recursive: improve rename/rename(1to2)/add[/add] handling Elijah Newren
2018-11-02 20:01 ` [PATCH] merge-recursive: combine error handling Derrick Stolee
2018-11-02 18:53 ` [RFC PATCH v4 09/10] fixup! merge-recursive: fix rename/add conflict handling Elijah Newren
2018-11-02 19:05 ` [PATCH v4 10/10] fixup! merge-recursive: improve rename/rename(1to2)/add[/add] handling Elijah Newren
2018-11-02 19:09 ` [PATCH v4 00/10] Improve path collision conflict resolutions Derrick Stolee
2018-11-02 20:06 ` Elijah Newren
2018-11-08 4:40 ` [PATCH v5 " Elijah Newren
2018-11-08 4:40 ` [PATCH v5 01/10] Add testcases for consistency in file collision conflict handling Elijah Newren
2018-11-08 4:40 ` [PATCH v5 02/10] t6036, t6042: testcases for rename collision of already conflicting files Elijah Newren
2018-11-08 4:40 ` [PATCH v5 03/10] merge-recursive: increase marker length with depth of recursion Elijah Newren
2018-11-08 4:40 ` [PATCH v5 04/10] merge-recursive: new function for better colliding conflict resolutions Elijah Newren
2018-11-08 4:40 ` [PATCH v5 05/10] merge-recursive: fix rename/add conflict handling Elijah Newren
2018-11-08 4:40 ` [PATCH v5 06/10] merge-recursive: improve handling for rename/rename(2to1) conflicts Elijah Newren
2018-11-08 4:40 ` [PATCH v5 07/10] merge-recursive: use handle_file_collision for add/add conflicts Elijah Newren
2018-11-08 4:40 ` [PATCH v5 08/10] merge-recursive: improve rename/rename(1to2)/add[/add] handling Elijah Newren
2018-11-08 4:40 ` [PATCH v5 09/10] t6036, t6043: increase code coverage for file collision handling Elijah Newren
2018-11-08 4:40 ` [PATCH v5 10/10] merge-recursive: combine error handling Elijah Newren
2018-11-08 5:25 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181102185317.31015-1-newren@gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=stolee@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.