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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux