February 2, 2023 11:17 AM, "Phillip Wood" [off-list ref] wrote:

Playing devil's advocate for a moment as we're not going to promise that the compressed output of
"git archive" will be stable in the future perhaps we should use this breakage as an opportunity to
highlight that to users and to advertize the config setting that allows them to use gzip for
compressing archives. Reverting the change gives the misleading impression that we're making a
commitment to keeping the output stable. The focus of this thread seems to be the problems relating
to github which they have already addressed.

I think there is general agreement that it is not practical to promise that the compressed output
of "git archive" is stable so maybe it is better to make that clear now while users can work around
it in the short term with a config setting rather than waiting until we're faced with some security
or other issue that forces a change to the output which users cannot work around so easily.

Reverting to the behavior of "use some arbitrary gzip from $PATH" would
be a poor decision whether or not git were willing to make some
commitment to gzip stability, because Git does not control arbitrary
gzips on the user's $PATH. If Git did want to promise gzip stability, it 
could only start from something like the current internal implementation
along with a vendored zlib; if it doesn't, as appears to be the case, 
then the internal implementation is superior for the other reasons 
already discussed.

If the user wants to depend on a particular gzip executable they supply, 
this configuration knob already exists for them.

Since there is no guarantee of stability, but there has been a popular 
misconception that there is some such guarantee (e.g., [1]), some kind 
of STABILITY section describing how there isn't any and suggesting ways
the user can attain more stability via configuration seems to be a good
idea.

[1]: https://lists.reproducible-builds.org/pipermail/rb-general/2021-October/002422.html