Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution

From: Eli Schwartz <eschwartz93@gmail.com>
Date: Jan 31, 2023, 09:11 UTC
Message-ID: <fd39ed5f-cee4-0d60-c0c2-fae18246fb53@gmail.com>
In-Reply-To: <230131.86357rrtsg.gmgdl@evledraar.gmail.com>

Quick response for now...

On 1/31/23 2:49 AM, Ævar Arnfjörð Bjarmason wrote:

Show 8 quoted lines

> So first, aside from whatever the git project does about the default,
> have you tried running the newer git version with a
> tar.tgz.command='gzip -cn' and seeing if it's compatible with the old
> version?
> 
> It's unclear from the blog post's "we are reverting this change for now"
> whether that meant a revert of the git version (probably), or a revert
> back to using gzip(1).

I do not know which one Github internally did, but I can confirm that the gzipped tarballs which github started shipping, when gunzipped, produced an uncompressed tarball that was byte-identical to uncompressed editions of the historic ones.

i.e. you could do this:

``` wget ${important_archive_release}

gzip -dc < ${important_archive_localfile} | gzip -cn > ${important_archive_localfile}.new ```

And:
- they have different checksums
- the .new file has reverted to the same checksum as historic versions
  from last year that are frozen into manifests

That was part of my original investigation, before I located the public conversations.

-- 
Eli Schwartz