Re: [PATCH v5 7/8] t7004: use single quotes instead of double quotes

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

 



AbdAlRahman Gad <abdobngad@xxxxxxxxx> writes:

> Some test bodies and test description are surrounded with double
> quotes instead of single quotes, violating our coding style.
>
> Signed-off-by: AbdAlRahman Gad <abdobngad@xxxxxxxxx>
> ---
>  t/t7004-tag.sh | 70 +++++++++++++++++++++++++-------------------------
>  1 file changed, 35 insertions(+), 35 deletions(-)

The conversion in this step can cause unintended breakage and needs
to be carefully done, so I checked with "git show -W" (I probably
should have done -U999 instead of just -W).

> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 2b15ede1f3..046a5bd9bc 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1583,7 +1583,7 @@ test_expect_success 'creating third commit without tag' '
>  
>  # simple linear checks of --continue
>  
> -test_expect_success 'checking that first commit is in all tags (hash)' "
> +test_expect_success 'checking that first commit is in all tags (hash)' '
>  	hash3=$(git rev-parse HEAD) &&

The original used to resolve "HEAD" while formulating the command
line of test_expect_success.  Now we resolve "HEAD" as the first
thing the body given to test_expect_success is run.  As HEAD does
not move between these two points in time, hash3 would get the same
value either way.


>  	cat >expected <<-\EOF &&
>  	v0.2.1
> @@ -1594,10 +1594,10 @@ test_expect_success 'checking that first commit is in all tags (hash)' "
>  	EOF
>  	git tag -l --contains $hash1 v* >actual &&
>  	test_cmp expected actual
> -"
> +'

The argument to the "--contains" option was interpolated while the
command line of test_expect_success was formulated.  If the body of
this test_expect_success modified the value of $hash1, this conversion
would have changed what the tested command did, but because nobody
assigns to $hash1 after it gets assigned (and this is true for other
$hash[0-9] variables), this conversion is OK.

>  for option in --contains --with --no-contains --without --merged --no-merged --points-at
>  do
> -	test_expect_success "mixing incompatible modes with $option is forbidden" "
> +	test_expect_success "mixing incompatible modes with $option is forbidden" '
>  		test_must_fail git tag -d $option HEAD &&
>  		test_must_fail git tag -d $option HEAD some-tag &&
>  		test_must_fail git tag -v $option HEAD
> -	"
> -	test_expect_success "Doing 'git tag --list-like $option <commit> <pattern> is permitted" "
> +	'
> +	test_expect_success "Doing 'git tag --list-like $option <commit> <pattern> is permitted" '
>  		git tag -n $option HEAD HEAD &&
>  		git tag $option HEAD HEAD &&
>  		git tag $option
> -	"
> +	'

Likewise.

The value of $option of course changes for each iteration of the
loop, and the original interpolated it into the tested scripts while
test_expect_success command lines were formulated in the original.
Now the variable $option is used just like any other variable while
the body is run, and the tested scripts behave identically either
way.

Looks good.  Thanks.




[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