Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:23

Jeff King [off-list ref] writes:
On Tue, Dec 03, 2013 at 10:21:35AM -0800, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help