All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
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 13:56:09 -0700	[thread overview]
Message-ID: <7vbqsra4d2.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <4493A810.6010706@lsrfire.ath.cx> (Rene Scharfe's message of "Sat, 17 Jun 2006 08:58:24 +0200")

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> | 1) The untar process creates a stray file "pax_global_header".
> | I am using GNU tar v1.13.22 and I get this message :
> |
> | ======================================================================
> | > tar jxf ~/u/source/git-1.4.0.tar.bz2
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> | file
> | ======================================================================
>
> You can ignore or delete that file.  It is a pax extended global header,
> containing the git commit ID as a comment.  GNU tar started supporting
> pax headers with version 1.13.93 (released 2004-02-23).  Version 1.13.22
> was released on 2001-08-29, by the way.  May I ask what operating system
> and version you are using?

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.

  reply	other threads:[~2006-06-17 20:56 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 [this message]
2006-06-17 21:55     ` Rene Scharfe
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=7vbqsra4d2.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=rene.scharfe@lsrfire.ath.cx \
    --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.