threads / patch / 42960

patchFix failing test t3700-add.sh

Subject: [PATCH] Fix failing test t3700-add.sh

## tl;dr

4 messages between Jul 29, 2016 and Jul 29, 2016. Diffs are folded; open one to read it.

replies: 3people: 4as markdown or json

Ingo Brückl· Jul 29, 2016, 12:31 UTC · lore

At the time of the test xfoo1 already exists and is a link. As a result, the check for file mode 100644 fails.

Create not yet existing file xfoo instead.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
---
 t/t3700-add.sh | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
Show changes to t/t3700-add.sh +6 −7
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 4865304..aee61b9 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -342,12 +342,12 @@ test_expect_success 'git add --chmod=+x stages a non-executable file with +x' '
 '

 test_expect_success 'git add --chmod=-x stages an executable file with -x' '
-	echo foo >xfoo1 &&
-	chmod 755 xfoo1 &&
-	git add --chmod=-x xfoo1 &&
-	case "$(git ls-files --stage xfoo1)" in
-	100644" "*xfoo1) echo pass;;
-	*) echo fail; git ls-files --stage xfoo1; (exit 1);;
+	echo foo >xfoo &&
+	chmod 755 xfoo &&
+	git add --chmod=-x xfoo &&
+	case "$(git ls-files --stage xfoo)" in
+	100644" "*xfoo) echo pass;;
+	*) echo fail; git ls-files --stage xfoo; (exit 1);;
 	esac
 '

--
2.9.2
Johannes Sixt· Jul 29, 2016, 16:23 UTC · re: Ingo Brückl · lore

Re: [PATCH] Fix failing test t3700-add.sh

Am 29.07.2016 um 14:31 schrieb Ingo Brückl:
Show 32 quoted lines
> At the time of the test xfoo1 already exists and is a link.
> As a result, the check for file mode 100644 fails.
>
> Create not yet existing file xfoo instead.
>
> Signed-off-by: Ingo Brückl <ib@wupperonline.de>
> ---
>  t/t3700-add.sh | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 4865304..aee61b9 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -342,12 +342,12 @@ test_expect_success 'git add --chmod=+x stages a non-executable file with +x' '
>  '
>
>  test_expect_success 'git add --chmod=-x stages an executable file with -x' '
> -	echo foo >xfoo1 &&
> -	chmod 755 xfoo1 &&
> -	git add --chmod=-x xfoo1 &&
> -	case "$(git ls-files --stage xfoo1)" in
> -	100644" "*xfoo1) echo pass;;
> -	*) echo fail; git ls-files --stage xfoo1; (exit 1);;
> +	echo foo >xfoo &&
> +	chmod 755 xfoo &&
> +	git add --chmod=-x xfoo &&
> +	case "$(git ls-files --stage xfoo)" in
> +	100644" "*xfoo) echo pass;;
> +	*) echo fail; git ls-files --stage xfoo; (exit 1);;
>  	esac
>  '

The commit that added this test is already 2 months old. How could that have been missed?

In fact, I cannot verify that there is xfoo1 in the directory or in the index before this test case runs. The general statement that the commit message makes is clearly not correct. What am I missing?

-- Hannes
Jeff King· Jul 29, 2016, 16:39 UTC · re: Ingo Brückl · lore

Re: [PATCH] Fix failing test t3700-add.sh

[+cc Ed, who wrote 4e55ed3 (add: add --chmod=+x / --chmod=-x options, 2016-05-31)]

On Fri, Jul 29, 2016 at 02:31:28PM +0200, Ingo Brückl wrote:
> At the time of the test xfoo1 already exists and is a link.
> As a result, the check for file mode 100644 fails.
> 
> Create not yet existing file xfoo instead.
Hrm. So in the original code:
Show 7 quoted lines
>  test_expect_success 'git add --chmod=-x stages an executable file with -x' '
> -	echo foo >xfoo1 &&
> -	chmod 755 xfoo1 &&
> -	git add --chmod=-x xfoo1 &&
> -	case "$(git ls-files --stage xfoo1)" in
> -	100644" "*xfoo1) echo pass;;
> -	*) echo fail; git ls-files --stage xfoo1; (exit 1);;

I would have expected "git add --chmod" to drop the "-x" bit in addition to actually overwriting the file contents (and switching a symlink to a file). And it does. The culprit is actually the "echo foo >xfoo1" line. If "xfoo1" is a symlink, then it silently writes to the symlink destination, and xfoo1 remains a symlink (and thus tweaking its execute bit is a noop).

I was also puzzled why the test fails for you; it does not for me. Running the test script as root does make it fail. There are some earlier tests which are skipped in this case, which run "git reset --hard" with xfoo1 in the index, which cleans it up.

Show 6 quoted lines
> +	echo foo >xfoo &&
> +	chmod 755 xfoo &&
> +	git add --chmod=-x xfoo &&
> +	case "$(git ls-files --stage xfoo)" in
> +	100644" "*xfoo) echo pass;;
> +	*) echo fail; git ls-files --stage xfoo; (exit 1);;

Here you just pick another name, "xfoo", which does happen to work. But it seems like that has the same potential for flakiness if earlier tests get adjusted or skipped, since they also use that name.

How about just:
  rm -f xfoo1

at the top of the test, which explicitly documents the state we are looking for?

I also wondered if this test, which calls "chmod 755 xfoo1", should be marked with the POSIXPERM prerequisite. But I guess since its goal is to strip the executable bit, it "works" even on systems where that chmod is a noop (the "git add --chmod" doesn't do anything, but one way or the other we end up at the end state we expect).

-Peff
Junio C Hamano· Jul 29, 2016, 16:49 UTC · re: Jeff King · lore

Re: [PATCH] Fix failing test t3700-add.sh

Jeff King <peff@peff.net> writes:
Show 22 quoted lines
> I was also puzzled why the test fails for you; it does not for me.
> Running the test script as root does make it fail. There are some
> earlier tests which are skipped in this case, which run "git reset
> --hard" with xfoo1 in the index, which cleans it up.
>
>> +	echo foo >xfoo &&
>> +	chmod 755 xfoo &&
>> +	git add --chmod=-x xfoo &&
>> +	case "$(git ls-files --stage xfoo)" in
>> +	100644" "*xfoo) echo pass;;
>> +	*) echo fail; git ls-files --stage xfoo; (exit 1);;
>
> Here you just pick another name, "xfoo", which does happen to work. But
> it seems like that has the same potential for flakiness if earlier tests
> get adjusted or skipped, since they also use that name.
>
> How about just:
>
>   rm -f xfoo1
>
> at the top of the test, which explicitly documents the state we are
> looking for?
That's much more sensible.
Show 5 quoted lines
> I also wondered if this test, which calls "chmod 755 xfoo1", should be
> marked with the POSIXPERM prerequisite. But I guess since its goal is to
> strip the executable bit, it "works" even on systems where that chmod is
> a noop (the "git add --chmod" doesn't do anything, but one way or the
> other we end up at the end state we expect).

We could make sure --chmod=[-+]x works both ways, which would be more robust on either type of underlying platform. Something along the lines of

	echo foo >xfoo1 &&
        git add --chmod=+x xfoo1 &&
        test_mode_in_index 100755 xfoo1 &&
        git add --chmod=-x xfoo1 &&
        test_mode_in_index 100644 xfoo1

with an obvious addition of a test_mode_in_index helper function as the same "case $(ls-files -s) in ... esac" pattern appears number of times.

← back to recent threads