Re: Sources for 3.18-rc1 not uploaded
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Oct 21, 2014, 08:08 UTC
- Message-ID
- <54461483.9010600@drmicha.warpmail.net>
- In-Reply-To
- <CA+55aFyZ1Mzjdx+JsD4jmFnJo+xL8xLz5+mtbh+_25bCak-7hQ@mail.gmail.com>
Linus Torvalds schrieb am 21.10.2014 um 01:17:
Show 20 quoted lines
> 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