All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.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: Tue, 21 Oct 2014 10:08:35 +0200	[thread overview]
Message-ID: <54461483.9010600@drmicha.warpmail.net> (raw)
In-Reply-To: <CA+55aFyZ1Mzjdx+JsD4jmFnJo+xL8xLz5+mtbh+_25bCak-7hQ@mail.gmail.com>

Linus Torvalds schrieb am 21.10.2014 um 01:17:
> On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>>
>> It doesn't appear that the stability of git archive --format=tar is
>> documented anywhere.  Given that, it doesn't seem reasonable to expect
>> that any tar implementation produces bit-for-bit compatible output
>> between versions.
> 
> The kernel has simple stability rules: if it breaks users, it gets
> fixed or reverted. That is a damn good rule.
> 
> I realize that some other projects are crap, and don't care about
> their users. I hope and believe that git is not in that sad group.
> 
> The whole "it's not documented" excuse is pure and utter bollocks.
> Users don't care. And stability of data should be *expected*, not need
> some random documentation entry to make it explicit.
> 
>                       Linus
> 

Linus, with all due respect, this is not the LKML, so please watch your
tone over here on the git list (and keep ranting on LKML however you want).

Brian made a very valid point about what his patch was trying to fix -
after all that is why it was applied. Konstantin made a very valid point
about why the existing behavior is useful for KUP. Interestingly, both
cared about the users of git, just different kinds users.

Git is probably one of the most conservative projects regarding
backwards compatibility and heeding users' expectations (sometimes to my
own dismay). That being said, we distinguish between justified
expectations and those without a solid base - which is why we have
porcelain vs. plumbing, for example, to make clear which part of the ui
is stable. (Yeah, I know you know, but you didn't argue as if you did.)

"data" in git is stable. "data exports" by git are as stable as the
output format is intrinsically or due to the (hopefully documented) way
git produces it.

Unfortunately, the git archive doc clearly says that the umask is
applied to all archive entries. And that clearly wasn't the case (for
extended metadata headers) before Brian's fix.

Brian: How old is the newest tar that get's the extended metadata
headers wrong? If those tars are a "real concern" then we should
probably do the extra pax_umask as suggested by Linus, but have the
default protect the "unknowing users" and give the "knowing users" that
config knob to twitch (sorry, Linus). Otherwise a revert is in order.

Michael

  reply	other threads:[~2014-10-21  8:08 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 [this message]
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

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=54461483.9010600@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.