All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: htl10@users.sourceforge.net
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: git-archive's wrong documentation: really write pax rather than tar
Date: Sat, 06 Aug 2011 20:57:45 +0200	[thread overview]
Message-ID: <4E3D8EA9.3000609@lsrfire.ath.cx> (raw)
In-Reply-To: <1312482802.68635.YahooMailClassic@web29518.mail.ird.yahoo.com>

Am 04.08.2011 20:33, schrieb Hin-Tak Leung:
> --- On Thu, 4/8/11, René Scharfe <rene.scharfe@lsrfire.ath.cx>
> wrote:
> 
>> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> <snipped>
>> Ah, here it is:
>> 
>> https://svn.r-project.org/R/trunk/src/library/utils/R/tar.R
>> 
>> It's the ctype handling in function untar2 that rejects unknown
>> entry types.
>> 
>> For reference, the documentation of the pax format including a 
>> suggestion to treat unknown types like regular files can be found
>> here (search for "typename"):
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
>> 
>>> I think I tried the tree example and the R code also
>> didn't like it
>>> much... may be I'll give it another try.
>> 
>> Did you try adding a ":" to the tree argument, e.g. this:
>> 
>> $ git archive HEAD:
>> 
>> instead of this?
>> 
>> $ git archive HEAD
>> 
>> René
> 
> That's better! With a HEAD: , that code does a lot of:
> 
> Warning in untar2(tarfile, files, list, exdir) : checksum error for
> entry 'file...'
> 
> for each file it tries to extract, but at least it is extracting the
> files. 

That doesn't sound good.  Looking at the R source, however, I can see
that they use a two different algorithms to compute the checksum than
the one specified by POSIX (even though I don't fully understand what it
actually is their doing, since I don't know R).  So worry too much about
the warning; as long e.g. "tar tf <file>" doesn't complain your archive
should be intact.

> I wasn't entirely sure about the notation used in the man page
> - is "v1.4.0^{tree}" same as "v1.4.0:" ? "HEAD:" is clearer, as most
> people has a HEAD...

They're a bit different in principle, but point to the same target in
this particular case.  "<ref>:<path>" gets you an object (blob or tree)
of a commit; with an empty <path> you get the root tree.
"<ref>^{<type>}" gives you the requested object of <type> (tag, commit
or tree) behind the <ref>; with "tree" you get the root tree of the commit.

René

  reply	other threads:[~2011-08-06 18:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 17:27 (unknown) Hin-Tak Leung
2011-08-04 17:54 ` git-archive's wrong documentation: really write pax rather than tar René Scharfe
2011-08-04 18:33   ` Hin-Tak Leung
2011-08-06 18:57     ` René Scharfe [this message]
2011-08-10  3:08       ` Hin-Tak Leung
2011-08-10 19:55         ` René Scharfe
  -- strict thread matches above, loose matches on Subject: below --
2011-08-03 22:17 Hin-Tak Leung
2011-08-04  1:41 ` Jeff King
2011-08-04  1:56   ` Junio C Hamano
2011-08-04  2:00     ` Jeff King
2011-08-04  2:25       ` Junio C Hamano
2011-08-04  2:29         ` Jeff King
2011-08-04 17:39           ` René Scharfe
2011-08-04  2:13   ` Jeff King
2011-08-04 22:51     ` Junio C Hamano

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=4E3D8EA9.3000609@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=git@vger.kernel.org \
    --cc=htl10@users.sourceforge.net \
    --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 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.