From: Junio C Hamano <gitster@pobox.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
infra-steering@kernel.org, Git Mailing List <git@vger.kernel.org>
Subject: Re: Sources for 3.18-rc1 not uploaded
Date: Tue, 21 Oct 2014 11:59:58 -0700 [thread overview]
Message-ID: <xmqqoat5z1sh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54459E49.3040908@linuxfoundation.org> (Konstantin Ryabitsev's message of "Mon, 20 Oct 2014 19:44:09 -0400")
Konstantin Ryabitsev <konstantin@linuxfoundation.org> 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 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.
While I agree that it is a nice "feature", I wish KUP folks thought
more about what should happen when the archive output _must_ change
when a more serious bug is discovered, and coordinated with us
better.
During a period where older and buggy versions of "git archive" are
used by some uploaders while a new version is used by others, KUP
could:
- avail itself to a version (or versions) of "git archive" so that
it can recreate both older and newer output;
- upon receiving a tarball and signature, try recreating newer
output and see if signature matches, and when the signature does
not match, recreate older output and try again.
And we could supply "git archive --compatible=v1.7" option in the
newer version if that is easier on KUP folks than having to keep
multiple installations of versions of "git archive" around.
While I am on the topic of KUP, one feature I wish, which is the
only thing that is preventing me from updating the preformatted
documentation https://www.kernel.org/pub/software/scm/git/docs/, is
to allow me to upload a single tarball and extract it at one
location (e.g. /pub/software/scm/git/docs/) while removing existing
files in that location (i.e. removing deleted files). Where do I
file such a feature request?
prev parent reply other threads:[~2014-10-21 19:00 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
2014-10-21 18:59 ` Junio C Hamano [this message]
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=xmqqoat5z1sh.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=infra-steering@kernel.org \
--cc=konstantin@linuxfoundation.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.