At the moment, when git-debpush constructs an orig tarball for a
1.0-with-diff source package (I'm using "bedstead" as an example), it
seems to run gzip like this (from strace):

execve("/usr/bin/gzip", ["gzip", "-cn"], ...

This means that it produces a tarball that's different from what uscan
produces.  uscan (from devscripts 2.26.5) runs gzip like this:

execve("/usr/bin/gzip", ["gzip", "-n", "--rsyncable", "-9"], ...

This means that 1.0-with-diff packages with orig tarballs made using
git-deborig get mismatches from orig-check:

https://orig-check.debian.net/orig-check/result/802f4ed0a9a76790799ff4484c1dbf04bda6c28357cd22d4130c40d9349883e7

I've checked two other tools that produce gzipped orig tarballs for
Debian source packages, and found:

dpkg-source -sU -b (dpkg-dev 1.23.4)
execve("/usr/bin/gzip", ["gzip", "-n", "--rsyncable", "-9"], ...

gbp export-orig (git-buildpackage 0.9.39)
execve("/usr/bin/gzip", ["gzip", "-n", "-c"],

So there seems to be a fairly even split.  I think that the options used
by dpkg-source are probably better, and arguably it's also the canonical
implementation.  So I think it would be a good idea for git-deborig to
adopt the same gzip settings as dpkg-source and uscan.

This would make it more likely that tarballs produced by git-deborig would
match those produced by uscan.

Ben Harris writes ("Bug#1126123: git-deborig: should maybe use gzip -n --rsyncable -9"):

Another consideration is that we might want to make them match what
you get from git forges' tarball download features.

Ian.

Ooh yes, that's a good idea.  I shall investigate what they do.

I have done some experiments.  My conclusion is that at the gzip level,
Salsa and GitHub both do exactly what git-deborig currently does.

But at the tar level they're slightly different.  Both Salsa and
GitHub name the top-level directory in the tar file after the repository
and tag name.  So if I'm generating a tar file for the tag
"upstream/3.252" from the repository "bedstead", the top-level directory
will be called "bedstead-upstream-3.252".  Meanwhile, git-deborig
names that directory after the Debian source package and the upstream
version.

What this means is that in the common case where the forge repository and
the Debian source package have the same name and the upstream tags are
bare version numbers, git-deborig will currently produce identical results
to both Salsa and GitHub (and I've tested this and got identical
compressed tarballs out of all three)

That suggests that git-deborig should not change its behaviour and it
would be better for uscan to change.  Except that maybe git-deborig could
name its top-level directory after the tag that it uses.  I'm not sure how
I feel about that.