development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-27 19:49:21 +00:00
Code Issues Packages Projects Releases Wiki Activity
git/contrib/subtree
History
Ævar Arnfjörð Bjarmason fee65b194d t/Makefile: don't remove test-results in "clean-except-prove-cache" 
When "make test" is run with the default of "DEFAULT_TEST_TARGET=test"
we'll leave the "test-results" directory in-place, but don't do so for
the "prove" target.

The reason for this is that when 28d836c815 (test: allow running the
tests under "prove", 2010-10-14) allowed for running the tests under
"prove" there was no point in leaving the "test-results" in place.

The "prove" target provides its own summary, so we don't need to run
"aggregate-results", which is the reason we have "test-results" in the
first place. See 2d84e9fb6d (Modify test-lib.sh to output stats to
t/test-results/*, 2008-06-08).

But in a subsequent commit test-lib.sh will start emitting reports of
memory leaks in test-results/*, and it will be useful to analyze these
after the fact.

This wouldn't be a problem as failing tests will halt the removal of
the files (we'll never reach "clean-except-prove-cache" from the
"prove" target), but will be subsequently as we'll want to report a
successful run, but might still have e.g. logs of known memory leaks
in test-results/*.

So let's stop removing this, it's sufficient that "make clean" removes
it, and that "pre-clean" (which both "test" and "prove" depend on)
will remove it, i.e. we'll never have a stale "test-results" because
of this change.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-27 16:35:40 -07:00
..
t t/Makefile: don't remove test-results in "clean-except-prove-cache" 2022-07-27 16:35:40 -07:00
.gitignore
COPYING
git-subtree.sh
git-subtree.txt
INSTALL
Makefile
README
todo

README 

Please read git-subtree.txt for documentation.

Please don't contact me using github mail; it's slow, ugly, and worst of
all, redundant. Email me instead at apenwarr@gmail.com and I'll be happy to
help.

Avery