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

> 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)?

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