> 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