Re: [PATCH 1/1] tests: fix gzip with exported GZIP variable in environment

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2013, 22:07 UTC
Message-ID: <xmqqbo0wjmnn.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20131204193232.GB11024@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 25 quoted lines

> On Tue, Dec 03, 2013 at 10:21:35AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > There are a few options I see:
>> >
>> >   1. Drop $GZIP variable, and hard-code the prerequisite check to
>> >      "gzip", which is what is being tested.
>> > ...
>> > I think I'd be in favor of (1). It's the simplest, and we have not seen
>> > any reports of people who do not actually have gzip called "gzip". Users
>> > can still override it via config if they really want to.
>> 
>> I am OK with (1).
>> 
>> A related tangent is that we may have to worry about is how/if a
>> random setting coming from GZIP in the environment (e.g. "GZIP=-1v")
>> would interfere with the test.  It may be the simplest to unset
>> $GZIP at the beginning of these tests, regardless of which of the
>> above three is taken.
>
> I don't think we should worry about it.
>
> There are two levels to consider here. One, people may put junk in their
> GZIP variable, which will impact normal running of git itself...

This wasn't something I was worried about. We should support reasonable setting of GZIP without breaking ourselves.

> That leaves options which change the compressed output, like "-9".

Yes, I was solely focusing on the stability of the tests.

> If somebody shows up complaining that a test fails when they have GZIP
> set, then that may be catching a bug, or it may be catching a fragility
> in the test. But since we do not have a real-world complaint yet, I'd
> rather leave it and judge when we have an actual case.

OK.