Re: [PATCH 04/11] t3030-merge-recursive: don't check the stderr of a subshell

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

 



SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:

> The two test checking 'git mmerge-recursive' in an empty worktree in
> ...
>  		GIT_INDEX_FILE="$PWD/ours-has-rename-index" &&
>  		export GIT_INDEX_FILE &&
>  		mkdir "$GIT_WORK_TREE" &&
> -		git read-tree -i -m $c7 &&
> -		git update-index --ignore-missing --refresh &&
> -		git merge-recursive $c0 -- $c7 $c3 &&
> -		git ls-files -s >actual-files
> -	) 2>actual-err &&
> -	>expected-err &&
> +		git read-tree -i -m $c7 2>actual-err &&
> +		test_must_be_empty expected-err &&
> +		git update-index --ignore-missing --refresh 2>actual-err &&
> +		test_must_be_empty expected-err &&
> +		git merge-recursive $c0 -- $c7 $c3 2>actual-err &&
> +		test_must_be_empty expected-err &&
> +		git ls-files -s >actual-files 2>actual-err &&
> +		test_must_be_empty expected-err

Where do the contents of all of these expected-err files come from?
Should all of the test_must_be_empty checks be checking actual-err
instead?




[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