From: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org, Michael Somos <somos@grail.cba.csuohio.edu>
Subject: Re: git-1.4.0 make problems
Date: Sat, 17 Jun 2006 23:55:15 +0200 [thread overview]
Message-ID: <44947A43.7070909@lsrfire.ath.cx> (raw)
In-Reply-To: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> I've been using (in my non-git related project aka day-job)
>
> git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
>
> to avoid this. Although all of my target machines have gtar that are
> recent enough so I do not need it, but when the tarball has version
> string in its name, there is not much point having the pax header to
> identify the contents (where the pax header shines is when the result
> does not have the version string in its name).
>
> This might be a sensible thing to do for our dist target as well.
> The product of our dist target is for people who build from the
> source to bootstrap themselves (if they have git, then fetching the
> source using git is preferred anyway), as opposed to using pre-built
> binaries, so being as friendly as we can to different implementations
> of tar is a good thing.
Hrm. Is the header really that unfriendly? With a non-POSIX tar you
get an extra file and a nice, if somewhat cryptic, reminder to upgrade
your archiver. ;-) Seriously, this is way below my annoyance-radar,
but I'm obviously biased.
What do you think about the following patch for starters? It adds an
example to the git-tar-tree documentation showing your "tree trick"
and corrects two formatting buglets.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 831537b..c93a8fe 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -45,11 +45,16 @@ git tar-tree HEAD | (cd /var/tmp/ && mkd
latest commit on the current branch, and extracts it in
`/var/tmp/junk` directory.
-git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz
+git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
Create a tarball for v2.6.17 release.
-git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar
+git tar-tree v2.6.17{caret}\{tree\} linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
+
+ Create a tarball for v2.6.17 release, but without a
+ global extended pax header.
+
+git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar::
Get a tarball v0.99 from example.com.
next prev parent reply other threads:[~2006-06-17 21:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-17 2:18 git-1.4.0 make problems Michael Somos
2006-06-17 6:58 ` Rene Scharfe
2006-06-17 20:56 ` Junio C Hamano
2006-06-17 21:55 ` Rene Scharfe [this message]
2006-06-17 22:40 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2006-06-17 10:16 Michael Somos
2006-06-17 13:09 ` Dennis Stosberg
2006-06-17 22:11 ` Rene Scharfe
2006-06-17 14:46 Michael Somos
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=44947A43.7070909@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=somos@grail.cba.csuohio.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.