From: brian m. carlson Date: Sat, 13 Apr 2019 22:16:46 GMT Subject: Re: [PATCH 2/2] archive: avoid spawning `gzip` Message-ID: <20190413221646.GL12419@genre.crustytoothpaste.net> In-Reply-To: <20190413015102.GC2040@sigill.intra.peff.net> On Fri, Apr 12, 2019 at 09:51:02PM -0400, Jeff King wrote: > I wondered how you were going to kick this in, since users can define > arbitrary filters. I think it's kind of neat to automagically convert > "gzip -cn" (which also happens to be the default). But I think we should > mention that in the Documentation, in case somebody tries to use a > custom version of gzip and wonders why it isn't kicking in. > > Likewise, it might make sense in the tests to put a poison gzip in the > $PATH so that we can be sure we're using our internal code, and not just > calling out to gzip (on platforms that have it, of course). > > The alternative is that we could use a special token like ":zlib" or > something to indicate that the internal implementation should be used > (and then tweak the baked-in default, too). That might be less > surprising for users, but most people would still get the benefit since > they'd be using the default config. I agree that a special value (or NULL, if that's possible) would be nicer here. That way, if someone does specify a custom gzip, we honor it, and it serves to document the code better. For example, if someone symlinked pigz to gzip and used "gzip -cn", then they might not get the parallelization benefits they expected. I'm fine overall with the idea of bringing the compression into the binary using zlib, provided that we preserve the "-n" behavior (producing reproducible archives). -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204