Jeff King [off-list ref] writes:
On Wed, Aug 03, 2011 at 06:56:41PM -0700, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
It might be a bit more obvious to find if we actually had a
--no-pax-header option, though.
Yeah, we would need to make sure that --no-pack-header causes a barf
for other backends, though. "struct archiver_args" right now seems to have
compression_level but I think it should just have "const char **" that is
interpreted by backends.
Actually, it is relevant for zip, too. The option should really be
called "--no-commit-id" or something similar. I don't think it's as big
a deal with zip (because there is no compatibility issue), but you may
want to omit the header for other reasons (e.g., because you know it
doesn't point to a commit that is public).
Hmm, perhaps. It indeed is an implementation detail of the tar backend
that the commit object name is stored in pax header, so --no-commit-id
might make sense from "git" point of view, but from the point of view of
OP that started this thread, he wouldn't care what that extra information
is --- it can be a commit object name or it can be phase of the moon when
the archive was made --- he just wants the extra header dropped.
So I dunno.
On Wed, Aug 03, 2011 at 07:25:32PM -0700, Junio C Hamano wrote:
quoted
Actually, it is relevant for zip, too. The option should really be
called "--no-commit-id" or something similar. I don't think it's as big
a deal with zip (because there is no compatibility issue), but you may
want to omit the header for other reasons (e.g., because you know it
doesn't point to a commit that is public).
Hmm, perhaps. It indeed is an implementation detail of the tar backend
that the commit object name is stored in pax header, so --no-commit-id
might make sense from "git" point of view, but from the point of view of
OP that started this thread, he wouldn't care what that extra information
is --- it can be a commit object name or it can be phase of the moon when
the archive was made --- he just wants the extra header dropped.
So I dunno.
If the intent of the option is "write plain-vanilla ustar" (I really
hope it doesn't need to be "plain-vanilla 4.3BSD tar"), then I think we
would do better to have a new --format type. Because from the OP's
perspective, it's not "drop this header that I don't like" but "make
something compatible with older versions of tar".
-Peff
Am 04.08.2011 04:29, schrieb Jeff King:
On Wed, Aug 03, 2011 at 07:25:32PM -0700, Junio C Hamano wrote:
quoted
quoted
Actually, it is relevant for zip, too. The option should really be
called "--no-commit-id" or something similar. I don't think it's as big
a deal with zip (because there is no compatibility issue), but you may
want to omit the header for other reasons (e.g., because you know it
doesn't point to a commit that is public).
Hmm, perhaps. It indeed is an implementation detail of the tar backend
that the commit object name is stored in pax header, so --no-commit-id
might make sense from "git" point of view, but from the point of view of
OP that started this thread, he wouldn't care what that extra information
is --- it can be a commit object name or it can be phase of the moon when
the archive was made --- he just wants the extra header dropped.
So I dunno.
If the intent of the option is "write plain-vanilla ustar" (I really
hope it doesn't need to be "plain-vanilla 4.3BSD tar"), then I think we
would do better to have a new --format type. Because from the OP's
perspective, it's not "drop this header that I don't like" but "make
something compatible with older versions of tar".
Yes, the commit ID header is just one part of this. Extended pax
headers are also used to store file names or symlink targets that are
too long. If none of this applies, the output should be pure ustar, though.
POSIX says that programs should treat unknown entry types just like
plain files and print an error message. You'd get an extra file named
pax_global_header, containing only the commit ID, and for long file
names extra files that contain them (and your original files would get
short names based on their object ID).
Looking at the web page linked to in the original post, the problem
seems to be that R (probably http://www.r-project.org/) uses "tar" as a
package format, seems to accept the ustar format but refuses pax
extended headers and thus is incompatible with "POSIX tar" and also
doesn't follow the suggestion to treat unknown entries as plain files.
We could add a "ustar" format that doesn't write commit ID comments and
errors out on file names that are too long.
René