René Scharfe l@web.de writes:
That's by design -- extended headers are meant to be extracted as
plain files by implementations that do not understand them.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html
says: If a particular implementation does not recognize the type,
Am 23.10.2014 um 03:09 schrieb brian m. carlson:
On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote:
Junio C Hamano schrieb am 21.10.2014 um 20:14:
Michael J Gruber g...@drmicha.warpmail.net writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to
On Sun, Oct 26, 2014 at 07:59:55PM +0100, René Scharfe wrote:
Am 23.10.2014 um 03:09 schrieb brian m. carlson:
The pax format is an extension of the tar format. All of the pax
implementations I've seen on Linux (OpenBSD's and MirBSD's) don't
actually understand the pax headers and emit them
Junio C Hamano schrieb am 21.10.2014 um 20:14:
Michael J Gruber g...@drmicha.warpmail.net writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an extended pax header an archive entry? I doubt it, and the
above is not relevant. The
On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote:
Junio C Hamano schrieb am 21.10.2014 um 20:14:
Michael J Gruber g...@drmicha.warpmail.net writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an extended pax
Linus Torvalds schrieb am 21.10.2014 um 01:17:
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
It doesn't appear that the stability of git archive --format=tar is
documented anywhere. Given that, it doesn't seem reasonable to expect
that any tar
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries. And that clearly wasn't the case (for
extended metadata headers) before Brian's fix.
Hey, it's time for another
Linus Torvalds torva...@linux-foundation.org writes:
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries. And that clearly wasn't the case (for
extended metadata
Michael J Gruber g...@drmicha.warpmail.net writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an extended pax header an archive entry? I doubt it, and the
above is not relevant. The mode bits for the archive entry that it
applies to
Konstantin Ryabitsev konstan...@linuxfoundation.org writes:
On 20/10/14 06:28 PM, brian m. carlson wrote:
Junio, quite frankly, I don't think that that fix was a good idea. I'd
suggest having a *separate* umask for the pax headers, so that we do
not break this long-lasting stability of git
Junio, Brian,
it seems that the stability of the git tar output is broken.
On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev
konstan...@linuxfoundation.org wrote:
Looks like 3.18-rc1 upload didn't work:
This is why the front page still lists 3.17 as the latest mainline. Want
to try
Linus Torvalds torva...@linux-foundation.org writes:
Junio, Brian,
it seems that the stability of the git tar output is broken.
On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev
konstan...@linuxfoundation.org wrote:
Looks like 3.18-rc1 upload didn't work:
This is why the front
On 20/10/14 02:28 PM, Junio C Hamano wrote:
I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more carefully, 2013-01-05), which
also should have broken bit-for-bit
Konstantin Ryabitsev konstan...@linuxfoundation.org writes:
On 20/10/14 02:28 PM, Junio C Hamano wrote:
I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more carefully,
On Mon, Oct 20, 2014 at 02:37:09PM -0400, Konstantin Ryabitsev wrote:
On 20/10/14 02:28 PM, Junio C Hamano wrote:
I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more
On Mon, Oct 20, 2014 at 08:25:59AM -0700, Linus Torvalds wrote:
Junio, Brian,
it seems that the stability of the git tar output is broken.
It doesn't appear that the stability of git archive --format=tar is
documented anywhere. Given that, it doesn't seem reasonable to expect
that any tar
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
It doesn't appear that the stability of git archive --format=tar is
documented anywhere. Given that, it doesn't seem reasonable to expect
that any tar implementation produces bit-for-bit compatible output
On 20/10/14 06:28 PM, brian m. carlson wrote:
Junio, quite frankly, I don't think that that fix was a good idea. I'd
suggest having a *separate* umask for the pax headers, so that we do
not break this long-lasting stability of git archive output in ways
that are unfixable and not
18 matches
Mail list logo
