Thread (21 messages) flat view 21 messages, 6 authors, 2016-06-15

Re: [RFC/PATCH 0/7] user-configurable git-archive output formats

From: René Scharfe <hidden>
Date: 2016-06-15 22:51:29

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help