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

[Junio C Hamano <gitster@pobox.com>]

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