git 2.10.1 test regression in t3700-add.sh

git 2.10.1 test regression in t3700-add.sh

[Jeremy Huddleston Sequoia]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

Hi Thomas,

I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS.

Let me know if you need any additional information to track these down.

Thanks,
Jeremy

not ok 40 - git add --chmod=[+-]x changes index with already added file
#	
#		echo foo >foo3 &&
#		git add foo3 &&
#		git add --chmod=+x foo3 &&
#		test_mode_in_index 100755 foo3 &&
#		echo foo >xfoo3 &&
#		chmod 755 xfoo3 &&
#		git add xfoo3 &&
#		git add --chmod=-x xfoo3 &&
#		test_mode_in_index 100644 xfoo3
#	

commit 610d55af0f082f6b866dc858e144c03d8ed4424c
Author: Thomas Gummerer <t.gummerer@gmail.com>
Date:   Wed Sep 14 22:07:47 2016 +0100

    add: modify already added files when --chmod is given
    
    When the chmod option was added to git add, it was hooked up to the diff
    machinery, meaning that it only works when the version in the index
    differs from the version on disk.
    
    As the option was supposed to mirror the chmod option in update-index,
    which always changes the mode in the index, regardless of the status of
    the file, make sure the option behaves the same way in git add.
    
    Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4465 bytes --]

Re: git 2.10.1 test regression in t3700-add.sh

[Jeremy Huddleston Sequoia]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]


> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
> 
> Hi Thomas,
> 
> I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS.
> 
> Let me know if you need any additional information to track these down.
> 
> Thanks,
> Jeremy
> 
> not ok 40 - git add --chmod=[+-]x changes index with already added file
> #	
> #		echo foo >foo3 &&
> #		git add foo3 &&
> #		git add --chmod=+x foo3 &&
> #		test_mode_in_index 100755 foo3 &&
> #		echo foo >xfoo3 &&
> #		chmod 755 xfoo3 &&
> #		git add xfoo3 &&
> #		git add --chmod=-x xfoo3 &&
> #		test_mode_in_index 100644 xfoo3
> #	
> 
> commit 610d55af0f082f6b866dc858e144c03d8ed4424c
> Author: Thomas Gummerer <t.gummerer@gmail.com>
> Date:   Wed Sep 14 22:07:47 2016 +0100
> 
>    add: modify already added files when --chmod is given
> 
>    When the chmod option was added to git add, it was hooked up to the diff
>    machinery, meaning that it only works when the version in the index
>    differs from the version on disk.
> 
>    As the option was supposed to mirror the chmod option in update-index,
>    which always changes the mode in the index, regardless of the status of
>    the file, make sure the option behaves the same way in git add.
> 
>    Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
>    Signed-off-by: Junio C Hamano <gitster@pobox.com>


This failure looks odd.  I'll dig into it a bit more as it looks like something odd is going on here...

expecting success: 
	echo foo >foo3 &&
	git add foo3 &&
	git add --chmod=+x foo3 &&
	test_mode_in_index 100755 foo3 &&
	echo foo >xfoo3 &&
	chmod 755 xfoo3 &&
	git add xfoo3 &&
	git add --chmod=-x xfoo3 &&
	test_mode_in_index 100644 xfoo3

pass
cannot chmod 'xfoo3'fail
120000 c5c4ca97a3a080c32920941b665e94a997901491 0	xfoo3
not ok 40 - git add --chmod=[+-]x changes index with already added file
#	
#		echo foo >foo3 &&
#		git add foo3 &&
#		git add --chmod=+x foo3 &&
#		test_mode_in_index 100755 foo3 &&
#		echo foo >xfoo3 &&
#		chmod 755 xfoo3 &&
#		git add xfoo3 &&
#		git add --chmod=-x xfoo3 &&
#		test_mode_in_index 100644 xfoo3
#	


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4465 bytes --]

Re: git 2.10.1 test regression in t3700-add.sh

[Jeremy Huddleston Sequoia]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

The issue is that the whitespace before the filename in $(git ls-files -s "$2") is a tab, and test_mode_in_index only looks for a space.

><

> On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
> 
> 
>> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
>> 
>> Hi Thomas,
>> 
>> I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS.
>> 
>> Let me know if you need any additional information to track these down.
>> 
>> Thanks,
>> Jeremy
>> 
>> not ok 40 - git add --chmod=[+-]x changes index with already added file
>> #	
>> #		echo foo >foo3 &&
>> #		git add foo3 &&
>> #		git add --chmod=+x foo3 &&
>> #		test_mode_in_index 100755 foo3 &&
>> #		echo foo >xfoo3 &&
>> #		chmod 755 xfoo3 &&
>> #		git add xfoo3 &&
>> #		git add --chmod=-x xfoo3 &&
>> #		test_mode_in_index 100644 xfoo3
>> #	
>> 
>> commit 610d55af0f082f6b866dc858e144c03d8ed4424c
>> Author: Thomas Gummerer <t.gummerer@gmail.com>
>> Date:   Wed Sep 14 22:07:47 2016 +0100
>> 
>>   add: modify already added files when --chmod is given
>> 
>>   When the chmod option was added to git add, it was hooked up to the diff
>>   machinery, meaning that it only works when the version in the index
>>   differs from the version on disk.
>> 
>>   As the option was supposed to mirror the chmod option in update-index,
>>   which always changes the mode in the index, regardless of the status of
>>   the file, make sure the option behaves the same way in git add.
>> 
>>   Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
>>   Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> 
> This failure looks odd.  I'll dig into it a bit more as it looks like something odd is going on here...
> 
> expecting success: 
> 	echo foo >foo3 &&
> 	git add foo3 &&
> 	git add --chmod=+x foo3 &&
> 	test_mode_in_index 100755 foo3 &&
> 	echo foo >xfoo3 &&
> 	chmod 755 xfoo3 &&
> 	git add xfoo3 &&
> 	git add --chmod=-x xfoo3 &&
> 	test_mode_in_index 100644 xfoo3
> 
> pass
> cannot chmod 'xfoo3'fail
> 120000 c5c4ca97a3a080c32920941b665e94a997901491 0	xfoo3
> not ok 40 - git add --chmod=[+-]x changes index with already added file
> #	
> #		echo foo >foo3 &&
> #		git add foo3 &&
> #		git add --chmod=+x foo3 &&
> #		test_mode_in_index 100755 foo3 &&
> #		echo foo >xfoo3 &&
> #		chmod 755 xfoo3 &&
> #		git add xfoo3 &&
> #		git add --chmod=-x xfoo3 &&
> #		test_mode_in_index 100644 xfoo3
> #	
> 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4465 bytes --]

Re: git 2.10.1 test regression in t3700-add.sh

[Jeremy Huddleston Sequoia]

[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]


> On Oct 9, 2016, at 20:22, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
> 
> The issue is that the whitespace before the filename in $(git ls-files -s "$2") is a tab, and test_mode_in_index only looks for a space.

Actually, looks like that as just a rabbit hole.  The real issue looks to be because an earlier test drops down xfoo3 as a symlink, which causes this test to fail due to the collision.  I'll get out a patch in a bit.

> 
>> <
> 
>> On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
>> 
>> 
>>> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> wrote:
>>> 
>>> Hi Thomas,
>>> 
>>> I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS.
>>> 
>>> Let me know if you need any additional information to track these down.
>>> 
>>> Thanks,
>>> Jeremy
>>> 
>>> not ok 40 - git add --chmod=[+-]x changes index with already added file
>>> #	
>>> #		echo foo >foo3 &&
>>> #		git add foo3 &&
>>> #		git add --chmod=+x foo3 &&
>>> #		test_mode_in_index 100755 foo3 &&
>>> #		echo foo >xfoo3 &&
>>> #		chmod 755 xfoo3 &&
>>> #		git add xfoo3 &&
>>> #		git add --chmod=-x xfoo3 &&
>>> #		test_mode_in_index 100644 xfoo3
>>> #	
>>> 
>>> commit 610d55af0f082f6b866dc858e144c03d8ed4424c
>>> Author: Thomas Gummerer <t.gummerer@gmail.com>
>>> Date:   Wed Sep 14 22:07:47 2016 +0100
>>> 
>>>  add: modify already added files when --chmod is given
>>> 
>>>  When the chmod option was added to git add, it was hooked up to the diff
>>>  machinery, meaning that it only works when the version in the index
>>>  differs from the version on disk.
>>> 
>>>  As the option was supposed to mirror the chmod option in update-index,
>>>  which always changes the mode in the index, regardless of the status of
>>>  the file, make sure the option behaves the same way in git add.
>>> 
>>>  Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
>>>  Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> 
>> 
>> This failure looks odd.  I'll dig into it a bit more as it looks like something odd is going on here...
>> 
>> expecting success: 
>> 	echo foo >foo3 &&
>> 	git add foo3 &&
>> 	git add --chmod=+x foo3 &&
>> 	test_mode_in_index 100755 foo3 &&
>> 	echo foo >xfoo3 &&
>> 	chmod 755 xfoo3 &&
>> 	git add xfoo3 &&
>> 	git add --chmod=-x xfoo3 &&
>> 	test_mode_in_index 100644 xfoo3
>> 
>> pass
>> cannot chmod 'xfoo3'fail
>> 120000 c5c4ca97a3a080c32920941b665e94a997901491 0	xfoo3
>> not ok 40 - git add --chmod=[+-]x changes index with already added file
>> #	
>> #		echo foo >foo3 &&
>> #		git add foo3 &&
>> #		git add --chmod=+x foo3 &&
>> #		test_mode_in_index 100755 foo3 &&
>> #		echo foo >xfoo3 &&
>> #		chmod 755 xfoo3 &&
>> #		git add xfoo3 &&
>> #		git add --chmod=-x xfoo3 &&
>> #		test_mode_in_index 100644 xfoo3
>> #	
>> 
> 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4465 bytes --]

Re: git 2.10.1 test regression in t3700-add.sh

[Junio C Hamano]

Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> writes:

> Actually, looks like that as just a rabbit hole.  The real issue
> looks to be because an earlier test drops down xfoo3 as a symlink,
> which causes this test to fail due to the collision.  I'll get out
> a patch in a bit.

[administrivia: please don't top-post, it is extremely hard to
follow what is going on]

There indeed is a test that creates xfoo3 as a symbolic link and
leaves it in the filesystem pointing at xfoo2 much earlier in the
sequence.  It seems that later one of the "add ignore-errors" tests
(there are two back-to-back) runs "git reset --hard" to make it (and
other symbolic links that are similarly named) go away, namely this
part of the code:

    test_expect_success POSIXPERM,SANITY 'git add --ignore-errors' '
            git reset --hard &&
            date >foo1 &&
            date >foo2 &&
            chmod 0 foo2 &&
            test_must_fail git add --verbose --ignore-errors . &&
            git ls-files foo1 | grep foo1
    '

    rm -f foo2

    test_expect_success POSIXPERM,SANITY 'git add (add.ignore-errors)' '
            git config add.ignore-errors 1 &&
            git reset --hard &&
            date >foo1 &&
            date >foo2 &&
            chmod 0 foo2 &&
            test_must_fail git add --verbose . &&
            git ls-files foo1 | grep foo1
    '
    rm -f foo2

"git reset --hard" in the first one, because these symbolic links
are not in the index at that point in the sequence, would leave them
untracked and in the working tree.  Then "add" is told to be
non-atomic with "--ignore-errors", adding them to the index while
reporting a failure.  When the test after that runs "git reset --hard"
again, because these symlinks are in the index (and not in HEAD),
they are removed from the working tree.

And that is why normal people won't see xfoo3 in later tests, like
the one you had trouble with.

Are you running without SANITY by any chance (I am not saying that
you are doing a wrong thing--just trying to make sure I am guessing
along the correct route)?

If that is the issue, then I think the right correction would be to
make sure that the files that an individual test expects to be
missing from the file system is indeed missing by explicitly
removing it, perhaps like this.

I also notice that the problematic test uses "chmod 755"; don't we
need POSIXPERM prerequisite on this test, too, I wonder?

Thanks.

-- >8 --
t3700: fix broken test under !SANITY

An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
already added files when --chmod is given", 2016-09-14) used "xfoo3"
as a test file.  The paths xfoo[1-3] were used by earlier tests for
symbolic links but they were expected to have been removed by the
test script reached this new test.

The removal with "git reset --hard" however happened in tests that
are protected by POSIXPERM,SANITY prerequisites.  Platforms and test
environments that lacked these would have seen xfoo3 as a leftover
symbolic link, pointing somewhere else, and chmod test would have
given a wrong result.



 t/t3700-add.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 924a266126..53c0cb6dea 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add --chmod=+x with symlinks' '
 '
 
 test_expect_success 'git add --chmod=[+-]x changes index with already added file' '
+	rm -f foo3 xfoo3 &&
 	echo foo >foo3 &&
 	git add foo3 &&
 	git add --chmod=+x foo3 &&

Re: git 2.10.1 test regression in t3700-add.sh

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> ...
> I also notice that the problematic test uses "chmod 755"; don't we
> need POSIXPERM prerequisite on this test, too, I wonder?
>
> Thanks.
>
> -- >8 --
> t3700: fix broken test under !SANITY
>
> An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
> already added files when --chmod is given", 2016-09-14) used "xfoo3"
> as a test file.  The paths xfoo[1-3] were used by earlier tests for
> symbolic links but they were expected to have been removed by the
> test script reached this new test.

Eh, "removed by the time test script reached..."

Re: git 2.10.1 test regression in t3700-add.sh

[Johannes Sixt]

Am 10.10.2016 um 19:41 schrieb Junio C Hamano:
> I also notice that the problematic test uses "chmod 755"; don't we
> need POSIXPERM prerequisite on this test, too, I wonder?

Good point. Without POSIXPERM the test demonstrate that, since chmod 755 
is basically a noop, the following add --chmod=-x does not leave an x 
bit in the index when there was none there in the first place. I think 
it does not hurt to keep the test even though it does not quite test the 
same thing as on POSIXPERM enabled systems.

-- Hannes

Re: git 2.10.1 test regression in t3700-add.sh

[Jeremy Huddleston Sequoia]

[-- Attachment #1: Type: text/plain, Size: 5149 bytes --]


> On Oct 10, 2016, at 10:41, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> writes:
> 
>> Actually, looks like that as just a rabbit hole.  The real issue
>> looks to be because an earlier test drops down xfoo3 as a symlink,
>> which causes this test to fail due to the collision.  I'll get out
>> a patch in a bit.
> 
> [administrivia: please don't top-post, it is extremely hard to
> follow what is going on]
> 
> There indeed is a test that creates xfoo3 as a symbolic link and
> leaves it in the filesystem pointing at xfoo2 much earlier in the
> sequence.  It seems that later one of the "add ignore-errors" tests
> (there are two back-to-back) runs "git reset --hard" to make it (and
> other symbolic links that are similarly named) go away, namely this
> part of the code:
> 
>    test_expect_success POSIXPERM,SANITY 'git add --ignore-errors' '
>            git reset --hard &&
>            date >foo1 &&
>            date >foo2 &&
>            chmod 0 foo2 &&
>            test_must_fail git add --verbose --ignore-errors . &&
>            git ls-files foo1 | grep foo1
>    '
> 
>    rm -f foo2
> 
>    test_expect_success POSIXPERM,SANITY 'git add (add.ignore-errors)' '
>            git config add.ignore-errors 1 &&
>            git reset --hard &&
>            date >foo1 &&
>            date >foo2 &&
>            chmod 0 foo2 &&
>            test_must_fail git add --verbose . &&
>            git ls-files foo1 | grep foo1
>    '
>    rm -f foo2
> 
> "git reset --hard" in the first one, because these symbolic links
> are not in the index at that point in the sequence, would leave them
> untracked and in the working tree.  Then "add" is told to be
> non-atomic with "--ignore-errors", adding them to the index while
> reporting a failure.  When the test after that runs "git reset --hard"
> again, because these symlinks are in the index (and not in HEAD),
> they are removed from the working tree.
> 
> And that is why normal people won't see xfoo3 in later tests, like
> the one you had trouble with.
> 
> Are you running without SANITY by any chance (I am not saying that
> you are doing a wrong thing--just trying to make sure I am guessing
> along the correct route)?

Ah, yep.  That's the ticket:

ok 23 # skip git add should fail atomically upon an unreadable file (missing SANITY of POSIXPERM,SANITY)
ok 24 # skip git add --ignore-errors (missing SANITY of POSIXPERM,SANITY)
ok 25 # skip git add (add.ignore-errors) (missing SANITY of POSIXPERM,SANITY)
ok 26 # skip git add (add.ignore-errors = false) (missing SANITY of POSIXPERM,SANITY)
ok 27 # skip --no-ignore-errors overrides config (missing SANITY of POSIXPERM,SANITY)

I dug into it a bit, and since I'm running the tests during a staging phase which runs as root, !SANITY gets set.  Should be solvable by essentially breaking test out into post-build instead of pre-install.  Thanks for the pointer there.


> If that is the issue, then I think the right correction would be to
> make sure that the files that an individual test expects to be
> missing from the file system is indeed missing by explicitly
> removing it, perhaps like this.
> 
> I also notice that the problematic test uses "chmod 755"; don't we
> need POSIXPERM prerequisite on this test, too, I wonder?
> 
> Thanks.
> 
> -- >8 --
> t3700: fix broken test under !SANITY
> 
> An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
> already added files when --chmod is given", 2016-09-14) used "xfoo3"
> as a test file.  The paths xfoo[1-3] were used by earlier tests for
> symbolic links but they were expected to have been removed by the
> test script reached this new test.
> 
> The removal with "git reset --hard" however happened in tests that
> are protected by POSIXPERM,SANITY prerequisites.  Platforms and test
> environments that lacked these would have seen xfoo3 as a leftover
> symbolic link, pointing somewhere else, and chmod test would have
> given a wrong result.
> 
> 
> 
> t/t3700-add.sh | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 924a266126..53c0cb6dea 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add --chmod=+x with symlinks' '
> '
> 
> test_expect_success 'git add --chmod=[+-]x changes index with already added file' '
> +	rm -f foo3 xfoo3 &&
> 	echo foo >foo3 &&
> 	git add foo3 &&
> 	git add --chmod=+x foo3 &&


I actually tried that, but the problem is that xfoo3 was previously added as a symlink, so test_mode_in_index still reports it as a symlink.

It's fundamentally a question of who is responsible for cleanup.  Is the individual test responsible for cleaning up after itself (such that later tests can rely on a clean state), or should individual tests assume that the initial state might be undefined and try to cleanup after earlier tests?  I'm in favor of either doing the former or ensuring that tests don't step on each-others toes.

--Jeremy


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4465 bytes --]

Re: git 2.10.1 test regression in t3700-add.sh

[Junio C Hamano]

Jeremy Huddleston Sequoia <jeremyhu@freedesktop.org> writes:

>> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
>> index 924a266126..53c0cb6dea 100755
>> --- a/t/t3700-add.sh
>> +++ b/t/t3700-add.sh
>> @@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add --chmod=+x with symlinks' '
>> '
>> 
>> test_expect_success 'git add --chmod=[+-]x changes index with already added file' '
>> +	rm -f foo3 xfoo3 &&
>> 	echo foo >foo3 &&
>> 	git add foo3 &&
>> 	git add --chmod=+x foo3 &&
>
>
> I actually tried that, but the problem is that xfoo3 was
> previously added as a symlink, so test_mode_in_index still reports
> it as a symlink.

Ah, of course.  That "rm -f" needs to remove from the index and also
from the working tree, so has to be "git rm -f --ignore-unmatch" or
something like that.

> It's fundamentally a question of who is responsible for cleanup.
> Is the individual test responsible for cleaning up after itself
> (such that later tests can rely on a clean state), or should
> individual tests assume that the initial state might be undefined
> and try to cleanup after earlier tests?

In modern tests, we strive to do the former with liberal use of
test_when_finished.  I think the one that creates xfoo[123] and
leaves them behind for a long time predates the modern practice.

A minimal fix with that approach may look like this:

 t/t3700-add.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 924a266126..80c7ee3e3b 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -64,6 +64,7 @@ test_expect_success 'git add: filemode=0 should not get confused by symlink' '
 test_expect_success \
 	'git update-index --add: Test that executable bit is not used...' \
 	'git config core.filemode 0 &&
+	 test_when_finished "git rm -f xfoo3" &&
 	 test_ln_s_add xfoo2 xfoo3 &&	# runs git update-index --add
 	 test_mode_in_index 120000 xfoo3'