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
Attachment:
signature.asc
Description: PGP signature
