Am 05.02.23 um 22:30 schrieb Ævar Arnfjörð Bjarmason: > > On Sat, Feb 04 2023, René Scharfe wrote: > >> Am 02.02.23 um 17:25 schrieb Junio C Hamano: >>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>> >>>> As the disruption of changing the default isn't worth it, let's use >>>> gzip(1) again by default, and only fall back on the new "git archive >>>> gzip" if it isn't available. >>> >>> It perhaps is OK, and lets us answer "ugh, the compressed output of >>> 'git archive' is unstable again" with "we didn't change anything, >>> perhaps you changed your gzip(1)?" when they fix bugs or improve >>> compression or whatever. Of course that is not an overall win for >>> the end users, but in the short term until gzip gets such a change, >>> we would presumably get the "same" output as before. >> >> Restoring the old default is an understandable reflex. In theory it >> worsens consistency and stability of the output, but in practice using >> whatever was found in $PATH did work before -- or at least it was not >> our problem if it didn't. > > "In theory" because the user might be flip-flopping between different > gzip(1) versions? No flopping needed. We can't control what's in $PATH. There are OS-specific replacements for GNU gzip in NetBSD/FreeBSD/macOS and OpenBSD. People could use pigz. Or cat, for that matter. Different versions of different tools might produce different output. There are alternative to the original libz as well, e.g. libz-ng. We don't control which one or which version is installed, either, but we could do so if we wanted by importing one of them like we did with LibXDiff. > Even if it wasn't for that breakage, I think 4/9 and 6/9 here show the > main problem you were trying to solve in making "git archive gzip" the > default didn't need to be solved by changing the default. I.e. the aim > was to have it work when "gzip(1)" wasn't available, which we can do by > falling back only if we can't invoke it, rather than changing the > long-standing default. The aim was to no longer depend on gzip. That goal was already met by providing the internal implementation, without changing the default. Git for Windows for example could use it in their config and drop gzip. Calling gzip if available, warning if it isn't and using the internal implementation adds yet more variance. No longer allowing gzip to be a shell alias might confuse someone. The automatic fallback would only benefit users that don't want to touch /etc/gitconfig, have nobody to do it for them and don't care about warnings -- hopefully not a big crowd. I didn't intend the change of default to be that painful, but don't see the point in going back now that we're through. The new default is better -- one less dependency to care about. And if we need to go back, however, then a know-good state makes more sense than a smart fallback with some new twists. René
