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

From: Eli Schwartz <eschwartz93@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"René Scharfe" <l.s.r@web.de>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Jeff King" <peff@peff.net>
Subject: Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution
Date: Tue, 31 Jan 2023 04:11:51 -0500	[thread overview]
Message-ID: <fd39ed5f-cee4-0d60-c0c2-fae18246fb53@gmail.com> (raw)
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:
> 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