Jonathan Nieder <jrnie...@gmail.com> writes:
> Jeff King wrote:
>> When I want to debug a failing test, I often end up doing:
>> cd t
>> ./t4107-<tab> -v -i
>> cd tra<tab>
>> The test names are long, so tab-completing on the trash directory is
>> very helpful. Lately I've noticed that there are a bunch of crufty trash
>> directories in my t/ directory, which makes my tab-completion more
> Ah, and if I'd read this then I wouldn't have had to be confused at
> all. Would it work to replace the commit message with something like
The third paragraph of 1/3 sufficiently covers it, no? We could add
"It makes it less convenient to use tab completion 'cd t/tra<TAB>'
to go to the trash directory of the failed test to inspect the
situation" after "... left in the t/ directory.", though.
Once upon a time, the test-lib library would create trash
directories in the current working directory, unless we were
explicitly told to put it elsewhere via --root. As a result,
t0000 created the sub-test trash directories inside its own
However, we noticed that this did not cover all cases, since
we would need to respect $TEST_OUTPUT_DIRECTORY even if
--root is not given (or is relative). Commit 38b074d fixed
this to consistently use the full path.
As a result, trash directories used by t0000's sub-tests are now
created in git's original test output directory rather than in our
trash directory. Furthermore, since some of the sub-tests simulate
failures, the trash directories do not get cleaned up, and the cruft
is left in the t/ directory.
We could fix this by passing a new "--root=$TRASH_DIRECTORY"
option to the sub-test. However, we do not want the sub-tests
to write anything at all to git's directory (e.g., they
should not be writing to t/test-results, either, although
this is already handled by separate code). So the best
solution is to simply reset $TEST_OUTPUT_DIRECTORY entirely
in the sub-test, which covers this case, as well as any
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html