Re: [PATCH 2/2] archive: support gzipped tar files

[Jeff King <peff@github.com>]

On Wed, Jun 15, 2011 at 08:40:22AM +0900, Miles Bader wrote:

> Jeff King <peff@github.com> writes:
> >> I didn't know it was that easy (primarily because I didn't know zlib had a
> >> ready-to-eat interface to do this).
> >
> > Yes, though I think it may be worth doing the more flexible,
> > external-filters approach. See elsewhere in the thread.
> 
> Given the relatively trivial code, isn't it worth doing both...?
>
> One method for flexibility/multi-threaded-speed, the other for
> portability/robustness (doesn't depend on configuration / setup
> details)...

Maybe, although the code is a little less trivial than I hoped (see
René's response for some bugs in my original series).

My series allowing external filters via configuration also comes with
builtin config for gzip. So there's no extra config or setup details for
the user, assuming they can run "gzip" from their PATH.

So I think the only disadvantage now is for people who don't have gzip
at all. I suspect people on such platforms are going to want another
format anyway, but we could still help them out. However, I think
instead of building it specially into the archive code, it would be
cleaner to simply ship a bare-bones version of gzip that only stdio
(i.e., a "git-gzip"). It would be no more code than what the internal
solution would be, it could be easier to read (since the program is
self-contained), and it benefits from the SMP speedup.

Although at the point we are shipping "git-gzip", I really have to
wonder if people wouldn't prefer to just install gzip themselves. So I'm
inclined to wait until somebody complains that git+zlib are easy to get
on their system, but gzip isn't.

-Peff