Re: Git generated tarballs and Debian

From: Theodore Tso <tytso@mit.edu>
Date: Apr 28, 2026, 11:50 UTC
Message-ID: <20260428115017.GA71700@macsyma-wired.lan>
In-Reply-To: <afCLFJX86yEPKKfk@fruit.crustytoothpaste.net>

On Tue, Apr 28, 2026 at 10:25:24AM +0000, brian m. carlson wrote:

Show 9 quoted lines

> 
> I'll just note that we don't make any guarantees that `git archive`
> produces identical output across versions.  Incorrectly making that
> assumption broke kernel.org when we changed the format in the past.
> 
> Also, if you use `export-subst`, then it's possible to emit short object
> IDs, which can differ in length depending on how many objects are in the
> repository.  It's also possible to use zlib or pigz instead of gzip to
> produce tarballs, in which case the compressed data will also differ.

This is what I've been using to try get reproducible tarballs for e2fprogs:

git archive --prefix=e2fsprogs-${ver}/ ${commit} | gzip -9n > $fn

,,, where $commit is a signed git tag.

I know that in the past, using --format=tgz has broken based on different compression parameters used by git (and whether it used an external or internal compressor). I also know that if $commit is a tree-id, this can result in the timestamps being not reproduible. I also don't use export-subst.

There is also the difference in the prefix used by github and gitlab, but that's arguably not git's fault.

What other gotchas are there? How is this likely to be inconsistent in the future? How much work is there to provide that guarantee in the future?

   	    	    	 	      	  - Ted

P.S. Although I use pristine-tar in Debian because I didn't want to count on git-archive being reproducible. But it would be lovely if I could make that guarantee starting on a particular git version.