git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).