From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Sat, 18 Jun 2011 15:40:47 GMT
Subject: Re: [RFC/PATCH 0/7] user-configurable git-archive output formats
Message-ID: <4DFCC6FF.8020801@lsrfire.ath.cx>
In-Reply-To: <20110615223030.GA16110@sigill.intra.peff.net>

Am 16.06.2011 00:30, schrieb Jeff King:
>   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.

Both can be done today, locally.  One just needs to add a tar-to-7z/any
program for 2.b). :)

Currently the easiest way to apply LZMA compression would be to pipe
--format=tar through the xz utils.  This method is supported by your
patches and the result can be read by 7-Zip.  It should be good enough
for most uses; I think we can disregard the whole point 2 until users
start to ask for these other formats or use cases.