René Scharfe 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, or
> th
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
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 writes:
Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries.
Is an
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 writes:
> >
> >> Unfortunately, the git archive doc clearly says that the umask is
> >> applied to all archive entries.
> >
> > Is an extended pax header "an ar
Junio C Hamano schrieb am 21.10.2014 um 20:14:
> Michael J Gruber 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 t
Konstantin Ryabitsev 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 archive" output i
Michael J Gruber 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 does not come from ther
Linus Torvalds writes:
> On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
> 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 tim
On Tue, Oct 21, 2014 at 1:08 AM, Michael J Gruber
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 round of the world-fam
Linus Torvalds schrieb am 21.10.2014 um 01:17:
> On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
> 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 bi
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 n
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
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
> between versions.
The ke
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
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 mo
Konstantin Ryabitsev 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, 2013-01-05), which
>> also s
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 compati
Linus Torvalds 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
> wrote:
>>
>> Looks like 3.18-rc1 upload didn't work:
>>
>> This is why the front page still lists 3.17 as the latest mainline. W
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
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 again?
Ok, tried again, a
18 matches
Mail list logo
