From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: David Tran <unsignedzero@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 03/12] t: drop useless sane_unset GIT_* calls
Date: Mon, 24 Mar 2014 17:56:38 -0400 [thread overview]
Message-ID: <20140324215638.GH13728@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqy503s0s0.fsf@gitster.dls.corp.google.com>
On Fri, Mar 21, 2014 at 02:24:31PM -0700, Junio C Hamano wrote:
> > Unsetting these is not only useless, but can be confusing to
> > a reader, who may wonder why some tests in a script unset
> > them and others do not (t0001 is particularly guilty of this
> > inconsistency, probably because many of its tests predate
> > the test-lib.sh environment-cleansing).
> [...]
> > I suppose one could make an argument that test-lib.sh may later change
> > the set of variables it clears, and these unsets are documenting an
> > explicit need of each test. I'd find that more compelling if it were
> > actually applied consistently.
>
> Hmph. I am looking at "git show HEAD^:t/t0001-init.sh" after
> applying this patch, and it does look consistently done with
> GIT_CONFIG and GIT_DIR (I am not sure about GIT_WORK_TREE but from a
> cursory read it is done consistently for tests on non-bare
> repositories).
I don't understand why we stop bothering with the unsets starting with
"init with --template". Are those variables not important to the outcome
of that and later tests, or did the author simply not bother because
they are noops?
> So I would actually agree with your alternative interpretation
> "Unsetting these is useless, but it does serve documentation
> purpose---without having to see what the state of the environment
> when the subprocess is started, the reader can understand what is
> being tested", rather than the one in the log message.
I'd agree with that if I were convinced that the presence of them there
versus the absence of them later was meaningful.
> Having said that, I am perfectly OK with the change to t0001 in this
> patch, if we added at the very beginning of the test sequence a
> comment that says:
>
> Below, creation and use of repositories are tested with various
> combinations of environment settings and command line flags.
> They are done inside subshells to avoid leaking temporary
> environment settings to later tests *and* assumes that the
> initial environment does not have have GIT_DIR, GIT_CONFIG, and
> GIT_WORK_TREE defined.
>
> or something.
I do not have a problem with that, as it implicitly covers all of the
tests following it. I do not think it is particularly necessary, though.
Assuming we start with a known test environment and avoiding polluting
it for further tests are basic principles of _all_ test scripts.
-Peff
next prev parent reply other threads:[~2014-03-24 21:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <244284@gmane.comp.version-control.git>
2014-03-18 12:08 ` [PATCH v2] tests: set temp variables using 'env' in test function instead of subshell David Tran
2014-03-18 20:37 ` Junio C Hamano
2014-03-18 21:45 ` Jeff King
2014-03-18 22:16 ` Junio C Hamano
2014-03-18 23:06 ` Jeff King
2014-03-19 17:28 ` Junio C Hamano
2014-03-20 23:11 ` [PATCH 0/12] GIT_CONFIG in the test suite Jeff King
2014-03-20 23:13 ` [PATCH 01/12] t/Makefile: stop setting GIT_CONFIG Jeff King
2014-03-20 23:13 ` [PATCH 02/12] t/test-lib: drop redundant unset of GIT_CONFIG Jeff King
2014-03-20 23:14 ` [PATCH 03/12] t: drop useless sane_unset GIT_* calls Jeff King
2014-03-21 21:24 ` Junio C Hamano
2014-03-24 21:56 ` Jeff King [this message]
2014-03-24 22:06 ` Junio C Hamano
2014-03-25 4:56 ` Junio C Hamano
2014-03-20 23:15 ` [PATCH 04/12] t: stop using GIT_CONFIG to cross repo boundaries Jeff King
2014-03-21 21:26 ` Junio C Hamano
2014-03-24 22:00 ` Jeff King
2014-03-20 23:15 ` [PATCH 05/12] t: prefer "git config --file" to GIT_CONFIG with test_must_fail Jeff King
2014-03-20 23:17 ` [PATCH 06/12] t: prefer "git config --file" to GIT_CONFIG Jeff King
2014-03-20 23:17 ` [PATCH 07/12] t0001: make symlink reinit test more careful Jeff King
2014-03-20 23:17 ` [PATCH 08/12] t0001: use test_path_is_* Jeff King
2014-03-20 23:18 ` [PATCH 09/12] t0001: use test_config_global Jeff King
2014-03-20 23:19 ` [PATCH 10/12] t0001: use test_must_fail Jeff King
2014-03-20 23:21 ` [PATCH 11/12] t0001: drop useless subshells Jeff King
2014-03-21 20:27 ` Eric Sunshine
2014-03-20 23:23 ` [PATCH 12/12] t0001: drop subshells just for "cd" Jeff King
2014-03-18 22:36 ` [PATCH v2] tests: set temp variables using 'env' in test function instead of subshell Eric Sunshine
2014-03-18 20:52 ` Eric Sunshine
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=20140324215638.GH13728@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=unsignedzero@gmail.com \
/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).