From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, git-dev@github.com
Subject: Re: [PATCH 2/2] archive: support gzipped tar files
Date: Tue, 14 Jun 2011 21:39:55 +0200 [thread overview]
Message-ID: <4DF7B90B.9050802@lsrfire.ath.cx> (raw)
In-Reply-To: <20110614181821.GA32685@sigill.intra.peff.net>
Am 14.06.2011 20:18, schrieb Jeff King:
> git-archive already supports the creation of tar files. For
> local cases, one can simply pipe the output to gzip, and
> having git-archive do the gzip is a minor convenience.
>
> However, when running git-archive against a remote site,
> having the remote side do the compression can save
> considerable bandwidth. Service providers could always wrap
> git-archive to provide that functionality, but this makes it
> much simpler.
That's a good point and one that was overlooked when this topic came up
earlier (see http://kerneltrap.org/mailarchive/git/2009/9/10/11507 and
http://kerneltrap.org/mailarchive/git/2009/9/11/11577). That
implementation was ... heavier than yours, but it also avoided an
unnecessary level of buffering. I wonder if it makes a measurable
difference, though.
> Creating gzipped archives is of course more expensive than
> regular tar archives; however, the amount of work should be
> comparable to that of creating a zip file, which is already
> possible. So there should be no new security implications
> with respect to creating load on a remote server.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/git-archive.txt | 17 +++++++++++++++--
> archive-tar.c | 27 +++++++++++++++++++++++++++
> archive.c | 1 +
> archive.h | 1 +
> builtin/archive.c | 6 ++++++
> t/t5000-tar-tree.sh | 26 ++++++++++++++++++++++++++
> 6 files changed, 76 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
> index 9c750e2..963bec4 100644
> --- a/Documentation/git-archive.txt
> +++ b/Documentation/git-archive.txt
> @@ -34,10 +34,11 @@ OPTIONS
> -------
>
> --format=<fmt>::
> - Format of the resulting archive: 'tar' or 'zip'. If this option
> + Format of the resulting archive: 'tar', 'tgz', or 'zip'. If this option
> is not given, and the output file is specified, the format is
> inferred from the filename if possible (e.g. writing to "foo.zip"
> - makes the output to be in the zip format). Otherwise the output
> + creates the output in the zip format; "foo.tgz" or "foo.tar.gz"
> + creates the output in the tgz format). Otherwise the output
> format is `tar`.
>
> -l::
> @@ -89,6 +90,12 @@ zip
> Highest and slowest compression level. You can specify any
> number from 1 to 9 to adjust compression speed and ratio.
>
> +tgz
> +~~~
> +-9::
> + Highest and slowest compression level. You can specify any
> + number from 1 to 9 to adjust compression speed and ratio.
> +
>
> CONFIGURATION
> -------------
> @@ -133,6 +140,12 @@ git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz::
>
> Create a compressed tarball for v1.4.0 release.
>
> +git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0
> +
> + Same as above, except that we use the internal gzip. Note that
> + the output format is inferred by the extension of the output
> + file.
> +
> git archive --format=tar --prefix=git-1.4.0/ v1.4.0{caret}\{tree\} | gzip >git-1.4.0.tar.gz::
>
> Create a compressed tarball for v1.4.0 release, but without a
> diff --git a/archive-tar.c b/archive-tar.c
> index b1aea87..86c8aa9 100644
> --- a/archive-tar.c
> +++ b/archive-tar.c
> @@ -260,3 +260,30 @@ int write_tar_archive(struct archiver_args *args)
> output = output_write;
> return write_tar_archive_internal(args);
> }
> +
> +static gzFile gz_file;
> +static void output_gz(const char *buf, unsigned long len)
> +{
> + if (!gzwrite(gz_file, buf, len))
> + die("unable to write compressed stream: %s",
> + gzerror(gz_file, NULL));
> +}
Does this do the right things when faced with interrupted writes or
truncated pipes? I ask because the earlier attempt had a
gzwrite_or_die() which did that, but I don't know anymore if that is
strictly needed. Oh, and bridging the gap between unsigned long and int
was certainly another reason for the existence of this function.
next prev parent reply other threads:[~2011-06-14 19:40 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 18:17 [PATCH 1/2] archive: factor out write phase of tar format Jeff King
2011-06-14 18:18 ` [PATCH 2/2] archive: support gzipped tar files Jeff King
2011-06-14 19:25 ` J.H.
2011-06-14 19:30 ` Jeff King
2011-06-14 19:39 ` René Scharfe [this message]
2011-06-14 20:14 ` Jeff King
2011-06-14 20:45 ` Jeff King
2011-06-15 22:30 ` [RFC/PATCH 0/7] user-configurable git-archive output formats Jeff King
2011-06-15 22:31 ` [PATCH 1/7] archive: reorder option parsing and config reading Jeff King
2011-06-15 22:33 ` [PATCH 2/7] archive: add user-configurable tar-filter infrastructure Jeff King
2011-06-15 23:33 ` Junio C Hamano
2011-06-16 0:29 ` Jeff King
2011-06-15 22:33 ` [PATCH 3/7] archive: support user tar-filters via --format Jeff King
2011-06-15 22:33 ` [PATCH 4/7] archive: advertise user tar-filters in --list Jeff King
2011-06-15 22:34 ` [PATCH 5/7] archive: refactor format-guessing from filename Jeff King
2011-06-15 23:48 ` Junio C Hamano
2011-06-16 0:34 ` Jeff King
2011-06-15 22:34 ` [PATCH 6/7] archive: match extensions from user-configured formats Jeff King
2011-06-15 22:35 ` [PATCH 7/7] archive: provide builtin .tar.gz filter Jeff King
2011-06-15 23:55 ` Junio C Hamano
2011-06-15 23:57 ` Junio C Hamano
2011-06-16 0:38 ` Jeff King
2011-06-16 6:27 ` Junio C Hamano
2011-06-16 6:51 ` Jeff King
2011-06-16 7:56 ` Chris Webb
2011-06-16 17:46 ` Jeff King
2011-06-16 18:02 ` Junio C Hamano
2011-06-16 18:21 ` Jeff King
2011-06-16 18:27 ` John Szakmeister
2011-06-16 18:42 ` Junio C Hamano
2011-06-16 18:57 ` Jeff King
2011-06-18 14:52 ` [RFC/PATCH 0/7] user-configurable git-archive output formats René Scharfe
2011-06-18 15:28 ` Jakub Narebski
2011-06-20 15:58 ` Junio C Hamano
2011-06-22 1:19 ` [PATCHv2 0/9] configurable tar compressors Jeff King
2011-06-22 1:20 ` [PATCHv2 1/9] archive: reorder option parsing and config reading Jeff King
2011-06-22 1:22 ` [PATCHv2 2/9] archive-tar: don't reload default config options Jeff King
2011-06-22 1:23 ` [PATCHv2 3/9] archive: refactor list of archive formats Jeff King
2011-06-23 17:05 ` Thiago Farina
2011-06-23 17:30 ` Jeff King
2011-06-22 1:24 ` [PATCHv2 4/9] archive: pass archiver struct to write_archive callback Jeff King
2011-06-22 1:24 ` [PATCHv2 5/9] archive: move file extension format-guessing lower Jeff King
2011-06-22 1:25 ` [PATCHv2 6/9] archive: refactor file extension format-guessing Jeff King
2011-06-22 1:26 ` [PATCHv2 7/9] archive: implement configurable tar filters Jeff King
2011-06-22 1:45 ` Jeff King
2011-06-22 6:09 ` René Scharfe
2011-06-22 14:59 ` Jeff King
2011-06-22 1:27 ` [PATCHv2 8/9] archive: provide builtin .tar.gz filter Jeff King
2011-06-22 1:35 ` [PATCHv2 9/9] upload-archive: allow user to turn off filters Jeff King
2011-06-22 3:17 ` Jeff King
2011-06-21 16:01 ` [RFC/PATCH 0/7] user-configurable git-archive output formats Jeff King
2011-06-18 15:40 ` René Scharfe
2011-06-14 20:30 ` [PATCH 2/2] archive: support gzipped tar files Junio C Hamano
2011-06-14 20:49 ` Jeff King
2011-06-14 23:40 ` Miles Bader
2011-06-15 22:46 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DF7B90B.9050802@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git-dev@github.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).