Re: [PATCH 1/9] t/: new helper for tests that pass with ort but fail with recursive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> +	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 ;-).

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux