Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2023, 23:37 UTC
Message-ID: <xmqqh6w5x8i8.fsf@gitster.g>
In-Reply-To: <Y9ry5Wxck4s/X2B+@tapette.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 8 quoted lines

> I don't think a blurb is necessary, but you're basically underscoring
> the problem, which is that nobody is willing to promise that compression
> is consistent, but yet people want to rely on that fact.  I'm willing to
> write and implement a consistent tar spec and to guarantee compatibility
> with that, but the tension here is that people also want gzip to never
> change its byte format ever, which frankly seems unrealistic without
> explicit guarantees.  Maybe the authors will agree to promise that, but
> it seems unlikely.

Just to step back a bit, where does the distinction between guaranteeing the tar format stability and gzip compressed bitstream stability come from? At both levels, the same thing can be expressed in multiple different ways, I think, but spelling out how exactly the compressor compresses is more involved than spelling out how entries in a tar archive is ordered and each entry is expressed, or something?

> That would probably break things, because gzip is GPLv3, and we'd need
> to ship a much older GPLv2 gzip, which would probably differ from the
> current behaviour, and might also have some security problems.

Yup, security issues may make bit-for-bit-stability unrealistic. IIRC, the last time we had discussion on this topic, we settled on stability across the same version of Git (i.e. deterministic result)?