On 3/25/2020 3:31 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@xxxxxxxxx>
>
> The untracked cache is caching wrong information, resulting in commands
> like `git status --porcelain` producing erroneous answers. The tests in
> t7063 actually have a wide enough test to catch a relevant case, in
> particular surrounding the directory 'dthree/', but it appears the
> answers were not checked quite closely enough and the tests were coded
> with the wrong expectation. Once the wrong info got into the cache in
> an early test, since later tests built on it, many others have a wrong
> expectation as well. This affects just over a third of the tests in
> t7063.
Wow. Good find.
> The error can be seen starting at t7063.12 (the first one switched from
> expect_success to expect_failure in this patch). That test runs in a
> directory with the following files present:
> done/one
> dthree/three
> dtwo/two
> four
> .gitignore
> one
> three
> two
>
> Of those files, the following files are tracked:
> done/one
> one
> two
>
> and the contents of .gitignore are:
> four
>
> and the contents of .git/info/exclude are:
> three
>
> And there is no core.excludesfile. Therefore, the following should be
> untracked:
> .gitignore
> dthree/
> dtwo/
> Indeed, these three paths are reported if you run
> git ls-files -o --directory --exclude-standard
> within this directory. However, 'git status --porcelain' was reporting
> for this test:
> A done/one
> A one
> A two
> ?? .gitignore
> ?? dtwo/
> which was clearly wrong -- dthree/ should also be listed as untracked.
> This appears to have been broken since the test was introduced with
> commit a3ddcefd97 ("t7063: tests for untracked cache", 2015-03-08).
> Correct the test to expect the right output, marking the test as failed
> for now. Make the same change throughout the remainder of the testsuite
> to reflect that dthree/ remains an untracked directory throughout and
> should be recognized as such.
I wonder if we could simultaneously verify these "expected" results match
using another command without the untracked cache? It's good that we have
the expected outputs explicitly, but perhaps double-checking the command
with `-c core.untrackedCache=false` would help us know these are the correct
expected outputs?
Thanks,
-Stolee
