Re: Sources for 3.18-rc1 not uploaded

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@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
> <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.