All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Junio C Hamano <gitster@pobox.com>,
	infra-steering@kernel.org, Git Mailing List <git@vger.kernel.org>
Subject: Re: Sources for 3.18-rc1 not uploaded
Date: Mon, 20 Oct 2014 19:44:09 -0400	[thread overview]
Message-ID: <54459E49.3040908@linuxfoundation.org> (raw)
In-Reply-To: <20141020222809.GB223410@vauxhall.crustytoothpaste.net>

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

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 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.
> It sounds like kernel.org has a bug, then.  Perhaps that's the
> appropriate place to fix the issue.

It's not a bug, it's a feature (TM). KUP relies on git-archive's ability
to create identical tar archives across platforms and versions. The
benefit is that Linus or Greg can create a detached PGP signature
against a tarball created from "git archive [tag]" on their system, and
just tell kup to create the same archive remotely, thus saving them the
trouble of uploading 80Mb each time they cut a release.

With their frequent travel to places where upload bandwidth is both slow
and unreliable, this ability to not have to upload hundreds of Mbs each
time they cut a release is very handy and certainly helps keep kernel
releases on schedule.

So, while it's fair to point out that git-archive was never intended to
always create bit-for-bit identical outputs, it would be *very nice* if
this remained in place, as at least one large-ish deployment (us) finds
it really handy.

-K


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]

  parent reply	other threads:[~2014-10-20 23:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141020115943.GA27144@gmail.com>
2014-10-20 15:25 ` Sources for 3.18-rc1 not uploaded Linus Torvalds
2014-10-20 18:28   ` Junio C Hamano
2014-10-20 18:37     ` Konstantin Ryabitsev
2014-10-20 19:43       ` Junio C Hamano
2014-10-20 21:52       ` Greg KH
2014-10-20 22:28   ` brian m. carlson
2014-10-20 23:17     ` Linus Torvalds
2014-10-21  8:08       ` Michael J Gruber
2014-10-21 16:25         ` Linus Torvalds
2014-10-21 17:25           ` David Kastrup
2014-10-21 18:14         ` Junio C Hamano
2014-10-22  9:42           ` Michael J Gruber
2014-10-23  1:09             ` brian m. carlson
2014-10-26 18:59               ` René Scharfe
2014-10-26 21:15                 ` brian m. carlson
2014-10-27 20:19                 ` Junio C Hamano
2014-10-20 23:44     ` Konstantin Ryabitsev [this message]
2014-10-21 18:59       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54459E49.3040908@linuxfoundation.org \
    --to=konstantin@linuxfoundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=infra-steering@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.