Re: Sources for 3.18-rc1 not uploaded

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2014, 18:28 UTC
Message-ID: <xmqqoat6389s.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CA+55aFyDuHskYE66rBVL_P-T2pxg6f2m6mUicfz-mk+ysePBxg@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 41 quoted lines

> 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
> <konstantin@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 again?
>
> Ok, tried again, and failed again.
>
>> If that still doesn't work, you may have to use version 1.7 of git when
>> generating the tarball and signature -- I recall Greg having a similar
>> problem in the past.
>
> Ugh, yes, that seems to be it. Current git generates different
> tar-files than older releases do:
>
>    tar-1.7.9.7 tar-cur differ: byte 107, line 1
>
> and a quick bisection shows that it is due to commit 10f343ea814f
> ("archive: honor tar.umask even for pax headers") in the current git
> development version.
>
> 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 compatible. kernel.org has relied (for a
> *long* time) on being able to just upload the signature of the
> resulting tar-file, because both sides can generate the same tar-fiel
> bit-for-bit.
>
> So instead of using "tar_umask", please make it use "tar_pax_umask",
> and have that default to 000. Ok?
>
> Something like the attached patch.
>
> Or just revert 10f343ea814f entirely.

My preference for this particular one however is to simply revert it. I do not see much point in bending backwards to treat older implementations of tar that do not understand extended pax headers very specially by adding a separate option or configuration, even though I wouldn't have minded if the original implementation were to apply the same umask for these entries that look like "dummy files" to them.

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 compatibility, went unnoticed, though. What I am getting at is that correcting past mistakes in the output should not be forbidden unconditionally with a complaint like this.

If 10f343ea were an important fix, then my preference would have been to instead add "tar_ignore_umask_in_pax_header" to allow those who care more about bit-for-bit compatibility with older broken versions than correctness to conditionally disable its code. But I do not think it is, so my preference isn't.

Thanks.