On Fri, Oct 23, 2020 at 9:48 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > 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@xxxxxxxxx>
> > ---
> > 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 ...
:-)
