Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Jan 31, 2023, 22:32 UTC
- Message-ID
- <Y9mXB1LaYSUJBlwF@tapette.crustytoothpaste.net>
- In-Reply-To
- <20230131150555.ewiwsbczwep6ltbi@meerkat.local>
On 2023-01-31 at 15:05:55, Konstantin Ryabitsev wrote:
Show 21 quoted lines
> On Tue, Jan 31, 2023 at 09:54:58AM +0000, brian m. carlson wrote: > > I'm one of the GitHub employees who chimed in there, and I'm also a Git > > contributor in my own time (and I am speaking here only in my personal > > capacity, since this is a personal address). I made a change some years > > back to the archive format to fix the permissions on pax headers when > > extracted as files, and kernel.org was relying on that and broke. Linus > > yelled at me because of that. > > > > Since then, I've been very opposed to us guaranteeing output format > > consistency without explicitly doing so. I had sent some patches before > > that I don't think ever got picked up that documented this explicitly. > > I very much don't want people to come to rely on our behaviour unless we > > explicitly guarantee it. > > I understand your position, but I also think it's one of those things that > happen despite your best efforts to prevent it. :) > > May I suggest adding a "git-archive --stable" that offers this guarantee, > simply as a matter of codifying the fact that the world has built > infrastructure around git's repeatable output. Maybe just for .tar (and > .tar.gz).
It is my intention to implement just .tar. That's my proposal: simply a pax-based format that serializes in a consistent way according to a predefined spec.
As far as whether other people want to implement consistent compression, they are welcome to also write a spec and implement it. I personally feel that's too hard to get right and am not planning on working on it.
-- brian m. carlson (he/him or they/them) Toronto, Ontario, CA