git 2.38.0: Change in `git archive` output

[FC Stegerman]

* kpcyrd <kpcyrd at archlinux.org> [2022-10-16 23:57]:
> multiple people in Arch Linux noticed the output of our `git archive`
> command doesn't match the tarball served by github anymore.
> 
> First I suspected an update in our gzip package until I found this line in
> the git 2.38.0 release notes:
> 
> > * Teach "git archive" to (optionally and then by default) avoid
> >   spawning an external "gzip" process when creating ".tar.gz" (and
> >   ".tgz") archives.
> 
> I've then found this commit that could be considered a breaking change in
> `git archive`:
> 
> https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710
> 
> I don't know if there's some kind of gzip standard that could be used to
> align the git internal gzip implementation with gnu gzip.
> 
> I'm not saying this is necessarily a bug or regression but it makes it
> harder to reproduce github tar balls from a git repository. Just sharing
> what I've debugged. :)

Thanks for the info!

FWIW, it looks like there's at least an easy workaround to get the old
behaviour:

  $ git -c tar.tgz.command="gzip -cn" archive --format=tgz HEAD > file.tgz
  $ git -c tar.tar.gz.command="gzip -cn" archive --format=tar.gz HEAD > file.tar.gz
  $ git archive --format=tar HEAD | gzip -cn > file.tgz

(I haven't actually been able to test these commands with git 2.38.0
yet, but they all produce an identical file with 2.37.2, and it
matches a github tarball when using the correct --prefix as well)

- FC