On Tue, Jun 14, 2011 at 04:45:21PM -0400, Jeff King wrote:
> The gzip path is not configurable at all. Probably it should read the
> path and arguments from the config file. In fact, we could even allow
> arbitrary config like:
>
> [tarfilter "tgz"]
> command = gzip -c
> extension = tgz
> extension = tar.gz
Here's a series implementing that. You can configure whatever you want,
and it includes builtin gzip configuration by default. You can override
to turn it off, or even switch it to run something like pigz instead.
My biggest reservation with the patches as-is is that they are very
tar-centric and not orthogonal. Specifically, they won't handle:
1. Other streamable archive formats you would want to pipe through
compressors. Do any of these actually exist? I guess we could offer
"pax" as a format eventually, and it might be like tar with
different defaults? I dunno.
Fixing this would not be too hard. Instead of these being
"tarfilters", they would be "archive filters", and they would chain
to some format, defaulting to "tar". Since there is no other
format right now, we could even punt on writing most of the code
until somebody adds one. But we would want to get the naming of the
config options right, since those are user-facing. Maybe
"archivefilter" (unfortunately the more readable archive.filter is
a little awkward with the way we parse config files)?
2. In theory you might want to plug in external helpers that are not
just stream filters, but actually their own container formats (like
zip). I think people who want 7zip would want this.
But how does git-archive interact with the helper? By definition
the data it wants is the set of files, not a single stream. So
either:
a. We give the helper a temporary exported checkout, and it
generates the stream from that.
b. We use tar as the lingua franca of streaming file containers,
and let the helper deal with converting to its preferred
output format.
Option (a) seems horribly inefficient on disk I/O. And if we did
want to do that, I think it's largely unrelated to this patch
series.
You can actually do option (b) with this series. In its worst
case, you can do the same as (a): just untar into a temporary
directory and compress from there. But a well-written helper could
convert tar into the output format on the fly.
The patches are:
[1/7]: archive: reorder option parsing and config reading
[2/7]: archive: add user-configurable tar-filter infrastructure
[3/7]: archive: support user tar-filters via --format
[4/7]: archive: advertise user tar-filters in --list
[5/7]: archive: refactor format-guessing from filename
[6/7]: archive: match extensions from user-configured formats
[7/7]: archive: provide builtin .tar.gz filter
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html