On 2023-02-01 at 09:40:57, Ævar Arnfjörð Bjarmason wrote:

"A spec" here seems like overkill to me, so far on that front we've been
shelling out to gzip(1), and the breakage/event that triggered this
thread is rectified by starting to do that again by default.

Sure, that will fix the immediate problem.

But so what? We don't need to make promises for all potential git
implementations, just this one. So we could add a blurb like this to the
docs:

	As people have come to rely on the exact "deflate"
	implementation "git archive" promises to invoke the system's
	"gzip" binary by default, under the assumption that its output
	is stable. If that's no longer the case you'll need to complain
	to whoever maintains your local "gzip".

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.

If we wanted to be even more helpful we could bunde and ship an old
version of GNU gzip with our sources, and either default to that, or
offer it as a "--stable" implementation of deflate.

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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA