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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Miles Bader <hidden>
Date: 2016-06-15 22:51:28

Jeff King [off-list ref] writes:
quoted
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)...

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

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

From: Jeff King <hidden>
Date: 2016-06-15 22:51:29

On Wed, Jun 15, 2011 at 08:40:22AM +0900, Miles Bader wrote:
Jeff King [off-list ref] writes:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help