From: Elijah Newren <newren@gmail.com> To: Junio C Hamano <gitster@pobox.com> Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>, Git Mailing List <git@vger.kernel.org> Subject: Re: [PATCH 1/9] t/: new helper for tests that pass with ort but fail with recursive Date: Fri, 23 Oct 2020 10:25:54 -0700 [thread overview] Message-ID: <CABPp-BEtBWktGB0ksfk5YLhVDfmUJ-QxUMiYtMANL1KhXd8qTA@mail.gmail.com> (raw) In-Reply-To: <xmqqr1pohos4.fsf@gitster.c.googlers.com> On Fri, Oct 23, 2020 at 9:48 AM Junio C Hamano <gitster@pobox.com> wrote: > > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > From: Elijah Newren <newren@gmail.com> > > > > There are a number of tests that the "recursive" backend does not handle > > correctly but which the redesign in "ort" will. Add a new helper in > > lib-merge.sh for selecting a different test expectation based on the > > setting of GIT_TEST_MERGE_ALGORITHM, and use it in various testcases to > > document which ones we expect to fail under recursive but pass under > > ort. > > > > Signed-off-by: Elijah Newren <newren@gmail.com> > > --- > > t/lib-merge.sh | 15 +++++++++++++++ > > t/t6416-recursive-corner-cases.sh | 11 ++++++----- > > t/t6422-merge-rename-corner-cases.sh | 7 ++++--- > > t/t6423-merge-rename-directories.sh | 13 +++++++------ > > t/t6426-merge-skip-unneeded-updates.sh | 3 ++- > > t/t6430-merge-recursive.sh | 3 ++- > > 6 files changed, 36 insertions(+), 16 deletions(-) > > create mode 100644 t/lib-merge.sh > > > > diff --git a/t/lib-merge.sh b/t/lib-merge.sh > > new file mode 100644 > > index 0000000000..fac2bc5919 > > --- /dev/null > > +++ b/t/lib-merge.sh > > @@ -0,0 +1,15 @@ > > +# Helper functions used by merge tests. > > + > > +test_expect_merge_algorithm () { > > + status_for_recursive=$1 > > + shift > > + status_for_ort=$1 > > + shift > > Smaller than minor, but I'd find > > status_for_recursive=$1 status_for_ort=$2 > shift 2 > > easier to see that which one is for which by matching the order in > which the calling sites, e.g. > > test_expect_merge_algorithm success failure \ > here comes the commands being tested > > lists them. I can fix that up. > > > + if test "$GIT_TEST_MERGE_ALGORITHM" = ort > > + then > > + test_expect_${status_for_ort} "$@" > > + else > > + test_expect_${status_for_recursive} "$@" > > + fi > > I expect this to be purely transitory, so it is fine. If not, > something along the lines of ... > > eval test_expect='$'status_for_"$GIT_TEST_MERGE_ALGORITHM" > $test_expect "$@" > > ... might be what I would suggest, though ;-). I also expect it to be transitory, but how long that transition is depends more on how long it takes for others to become comfortable with removing merge-recursive.c once merge-ort.c is in place. I suspect at a minimum it's a cycle or two after ort becomes the default (which at a minimum would come a cycle or two after ort is finished and available). If for some reason folks don't eventually become comfortable with removing merge-recursive, then we might need to revisit. > And the users are just too pleasant to see, with full of "failure > sucess", which is the second best outcome we want to see ;-) > > > +test_expect_merge_algorithm failure success 'check symlink mo... > > +test_expect_merge_algorithm failure success 'check symlink ad... > > +test_expect_merge_algorithm failure success 'check submodule ... > > +test_expect_merge_algorithm failure success 'check submodule ... > > +test_expect_merge_algorithm failure success 'check conflictin... > > +test_expect_merge_algorithm failure success 'rad-check: renam... > > +test_expect_merge_algorithm failure success 'rrdd-check: rena... > > +test_expect_merge_algorithm failure success 'mod6-check: chai... > > +test_expect_merge_algorithm failure success '6b1: Same rename... > > +test_expect_merge_algorithm failure success '6b2: Same rename... > > +test_expect_merge_algorithm failure success '10e: Does git co... > > +test_expect_merge_algorithm failure success '12b1: Moving two... > > +test_expect_merge_algorithm failure success '12c1: Moving one... > > +test_expect_merge_algorithm failure success '12f: Trivial dir... > > +test_expect_merge_algorithm failure success '4a: Change on A,... > > +test_expect_merge_algorithm failure success 'merge-recursive ... :-)
next prev parent reply other threads:[~2020-10-23 17:26 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 [this message] 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 ` [PATCH 3/9] t6416: correct expectation for rename/rename(1to2) + directory/file Elijah Newren via GitGitGadget 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=CABPp-BEtBWktGB0ksfk5YLhVDfmUJ-QxUMiYtMANL1KhXd8qTA@mail.gmail.com \ --to=newren@gmail.com \ --cc=git@vger.kernel.org \ --cc=gitgitgadget@gmail.com \ --cc=gitster@pobox.com \ --subject='Re: [PATCH 1/9] t/: new helper for tests that pass with ort but fail with recursive' \ /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).