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 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
