Re: [PATCH 0/9] git archive: use gzip again by default, document output stabilty

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 5, 2023, 21:30 UTC
Message-ID: <230205.86mt5r7q2e.gmgdl@evledraar.gmail.com>
In-Reply-To: <c3f215ca-b4ae-79a2-c14a-3c0f1799e6f7@web.de>

On Sat, Feb 04 2023, René Scharfe wrote:

Show 18 quoted lines

> Am 02.02.23 um 17:25 schrieb Junio C Hamano:
>> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> 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?

Show 6 quoted lines

> Are there still people left that would benefit from such a step back,
> however?  As far as I understand forges like GitHub relied on git
> archive producing the same tgz output across versions.  That assumption
> was violated, trust lost.  They had to learn about the configuration
> option tar.tgz.command or find some other way to cope.  Changing the
> default again won't undo that.

I think it's safe to assume that git is used by enough users that anything breaking at a major hosting provider is likely to have a very long tail in the wild, almost all of which we'll never see in "this broke for me" reports to this ML.

So no, that ship has clearly sailed for GitHub, but this series aims to address more than that.

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.