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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 1, 2023, 09:40 UTC
Message-ID: <230201.86pmatr9mj.gmgdl@evledraar.gmail.com>
In-Reply-To: <Y9mXB1LaYSUJBlwF@tapette.crustytoothpaste.net>

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.