On Tue, Jan 31 2023, brian m. carlson wrote:

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.

"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.

It means that someone writing a clean-room implementation of git would
likely run into the same issue, if they used e.g. the Go language and a
native Go implementation of deflate.

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".

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 be going above & beyond what's needed IMO, but still a lot
easier than the daunting task of writing a specification that exactly
described GNU gzip's current behavior, to the point where you could
clean-room implement it and be guaranteed byte-for-byte compatibility.