From: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>, Elijah Newren <newren@gmail.com>
Subject: [PATCH 3/9] t6416: correct expectation for rename/rename(1to2) + directory/file
Date: Fri, 23 Oct 2020 16:01:18 +0000 [thread overview]
Message-ID: <1eae84b7878dc6ebe7ee1fb4e860c316cd773ad5.1603468885.git.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.769.git.1603468885.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
When files are renamed and modified, we need to do three-way content
merges to get the appropriate content in the right location. When we
have a rename/rename(1to2) conflict (both sides rename the same file,
but differently), that merged content should be placed in each of the
two resulting files. merge-recursive handled that fine when that was
all that was involved, but when one or more of the two resulting files
were ALSO involved in a directory/file conflict, it failed to propagate
the merged content to that file. Unfortunately, the one test in t6416
that touched on this combination of cases had been coded to not expect
the merged contents to be present.
Fix the test to check for the right behavior, and record how the
different merge backends will be expected to handle it.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
t/t6416-recursive-corner-cases.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t6416-recursive-corner-cases.sh b/t/t6416-recursive-corner-cases.sh
index 0317e83970..887c2195a9 100755
--- a/t/t6416-recursive-corner-cases.sh
+++ b/t/t6416-recursive-corner-cases.sh
@@ -786,7 +786,7 @@ test_expect_success 'merge of D1 & E3 succeeds' '
)
'
-test_expect_success 'merge of D1 & E4 notifies user a and a2 are related' '
+test_expect_merge_algorithm failure success 'merge of D1 & E4 puts merge of a and a2 in both a and a2' '
test_when_finished "git -C directory-file reset --hard" &&
test_when_finished "git -C directory-file clean -fdqx" &&
(
@@ -804,7 +804,7 @@ test_expect_success 'merge of D1 & E4 notifies user a and a2 are related' '
test_line_count = 1 out &&
git rev-parse >expect \
- A:ignore-me B:a D1:a E4:a2 &&
+ A:ignore-me B:a E4:a2 E4:a2 &&
git rev-parse >actual \
:0:ignore-me :1:a~Temporary\ merge\ branch\ 2 :2:a :3:a2 &&
test_cmp expect actual
--
gitgitgadget
next prev parent reply other threads:[~2020-10-23 16:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 16:01 [PATCH 0/9] Support both merge backends in the testsuite, via environment variable Elijah Newren via GitGitGadget
2020-10-23 16:01 ` [PATCH 1/9] t/: new helper for tests that pass with ort but fail with recursive Elijah Newren via GitGitGadget
2020-10-23 16:48 ` Junio C Hamano
2020-10-23 17:25 ` Elijah Newren
2020-10-23 18:27 ` Elijah Newren
2020-10-24 10:49 ` Đoàn Trần Công Danh
2020-10-24 16:53 ` Elijah Newren
2020-10-25 13:49 ` Đoàn Trần Công Danh
2020-10-26 14:56 ` Elijah Newren
2020-10-26 17:43 ` Junio C Hamano
2020-10-23 16:01 ` [PATCH 2/9] merge tests: expect improved directory/file conflict handling in ort Elijah Newren via GitGitGadget
2020-10-23 17:40 ` Elijah Newren
2020-10-23 16:01 ` Elijah Newren via GitGitGadget [this message]
2020-10-23 16:01 ` [PATCH 4/9] t6404, t6423: expect improved rename/delete handling in ort backend Elijah Newren via GitGitGadget
2020-10-23 16:01 ` [PATCH 5/9] t6423: expect improved conflict markers labels in the " Elijah Newren via GitGitGadget
2020-10-23 16:01 ` [PATCH 6/9] merge tests: expect slight differences in output for recursive vs. ort Elijah Newren via GitGitGadget
2020-10-24 16:06 ` Elijah Newren
2020-10-23 16:01 ` [PATCH 7/9] t6423, t6436: note improved ort handling with dirty files Elijah Newren via GitGitGadget
2020-10-23 16:01 ` [PATCH 8/9] t6423: note improved ort handling with untracked files Elijah Newren via GitGitGadget
2020-10-23 16:01 ` [PATCH 9/9] t6423: add more details about direct resolution of directories Elijah Newren via GitGitGadget
2020-10-23 20:12 ` Elijah Newren
2020-10-26 17:01 ` [PATCH v2 0/9] Support both merge backends in the testsuite, via environment variable Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 1/9] t/: new helper for tests that pass with ort but fail with recursive Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 2/9] merge tests: expect improved directory/file conflict handling in ort Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 3/9] t6416: correct expectation for rename/rename(1to2) + directory/file Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 4/9] t6404, t6423: expect improved rename/delete handling in ort backend Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 5/9] t6423: expect improved conflict markers labels in the " Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 6/9] merge tests: expect slight differences in output for recursive vs. ort Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 7/9] t6423, t6436: note improved ort handling with dirty files Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 8/9] t6423: note improved ort handling with untracked files Elijah Newren via GitGitGadget
2020-10-26 17:01 ` [PATCH v2 9/9] t6423: add more details about direct resolution of directories Elijah Newren via GitGitGadget
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=1eae84b7878dc6ebe7ee1fb4e860c316cd773ad5.1603468885.git.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--subject='Re: [PATCH 3/9] t6416: correct expectation for rename/rename(1to2) + directory/file' \
/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
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 NNTP newsgroup(s).