git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
	git@vger.kernel.org, John Keeping <john@keeping.me.uk>,
	Thomas Rast <tr@thomasrast.ch>
Subject: Re: [PATCH 0/3] t0000 cleanups
Date: Mon, 30 Dec 2013 10:51:25 -0800	[thread overview]
Message-ID: <20131230185125.GI20443@google.com> (raw)
In-Reply-To: <xmqqwqimry2j.fsf@gitster.dls.corp.google.com>

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@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
>>> annoying.
>>
>> Ah, and if I'd read this then I wouldn't have had to be confused at
>> all.
[...]
> 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.
[4 paragraphs snipped]

I think it can be better, since the commit message left me scratching
my head while the patch itself seems pretty simple.  How about
something like the following?

First, describing the problem:

	Running t0000 produces more trash directories than expected
	and does not clean up after itself:

	 $ ./t0000-basic.sh
	[...]
	 $ ls -d trash\ directory.*
	 trash directory.failing-cleanup
	 trash directory.mixed-results1
	 trash directory.mixed-results2
	 trash directory.partial-pass
	 trash directory.test-verbose
	 trash directory.test-verbose-only-2

Analysis and fix:

	These scratch areas for sub-tests should be under the t0000
	trash directory, but because the TEST_OUTPUT_DIRECTORY
	setting from the toplevel test leaks into the environment
	they are created under the toplevel output directory (typically
	t/) instead.  Because some of the sub-tests simulate failures,
	their trash directories are kept around.

	Fix it by explicitly setting TEST_OUTPUT_DIRECTORY appropriately
	for sub-tests.

And then, optionally, describing rejected alternatives:

	An alternative fix would be to pass the --root parameter that
	only specifies where to put the trash directories, which would
	also work.  However, using TEST_OUTPUT_DIRECTORY is more
	futureproof in case tests want to write more output in
	addition to the test-results/ (which are already suppressed in
	sub-tests using the HARNESS_ACTIVE setting) and trash
	directories.

And more analysis of why this wasn't caught in the first place:

	This fixes a regression introduced by 38b074d (t/test-lib.sh:
	fix TRASH_DIRECTORY handling, 2013-04-14).  Before then, the
	TEST_OUTPUT_DIRECTORY setting was not respected consistently
	so most tests did their work in a "trash" subdirectory of the
	current directory instead of the output dir.

Does that make sense?

Thanks,
Jonathan

  reply	other threads:[~2013-12-30 18:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-28  9:27 [PATCH 0/3] t0000 cleanups Jeff King
2013-12-28  9:29 ` [PATCH 1/3] t0000: set TEST_OUTPUT_DIRECTORY for sub-tests Jeff King
2013-12-28 22:13   ` Jonathan Nieder
2013-12-28 22:20     ` Jonathan Nieder
2013-12-29  7:17     ` Jeff King
2013-12-28  9:31 ` [PATCH 2/3] t0000: simplify HARNESS_ACTIVE hack Jeff King
2013-12-28 22:14   ` Jonathan Nieder
2013-12-28  9:33 ` [PATCH 3/3] t0000: drop "known breakage" test Jeff King
2013-12-28 20:51   ` Jonathan Nieder
2013-12-29  7:22     ` Jeff King
2013-12-28 22:21 ` [PATCH 0/3] t0000 cleanups Jonathan Nieder
2013-12-30 18:30   ` Junio C Hamano
2013-12-30 18:51     ` Jonathan Nieder [this message]
2013-12-30 19:24       ` Junio C Hamano
2013-12-31 10:33       ` Jeff King
2014-01-02 22:28         ` Jonathan Nieder
2014-01-02 22:41           ` Junio C Hamano
2014-01-03  1:04           ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131230185125.GI20443@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    --cc=peff@peff.net \
    --cc=tr@thomasrast.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).