On Sun, 13 Sep 2026 10:48:24 +0100, Ian Jackson wrote:
Hi. Thanks for the report.
Thanks for the quick and detailed reply!
gregor herrmann writes ("Bug#1147543: git-debpush stumbles over .gitignore"):git debpush doesn't handle this situation; all I get is a failure email _after_ the attempted upload:...fatal: path '.gitignore' does not exist in 'caea8b14b213a4a16c5edfb95dca6de58a9d9b56'
Another thing we could do is change the behaviour of git-debpush, so that it would specify some different tag and tree. But there is no such tag and tree in this scenario (and I doubt we'd want git-debpush to make one) - and git-debpush couldn't even detect this situation without running pristine-tar locally. The underlying difficulty is that in this situation, the .gitignore contents are expressed only in the xdelta diff in the pristine-tar branch. In general, this is a very bad way to convey intended source package contents. (dgit push doesn't have this difficulty, because it has the tarball right there already.
Right, that was my guess, thanks for the confirmation.
The other possible workaorund would be to elide the upstream gitignores when making source packages, and canonical git branches, like dpkg-source does. That would be a DFSG violation. (Yes, I am saying that dpkg-source is automating DFSG violations - see below!)
Which wouldn't help when t2u creates the .orig.tar.gz with pristine-tar either, unless it does some "massaging" afterwords.
Which doesn't sound like a good idea …
We have been muddling through with various workarounds (including the one in dgit push where it makes a .gitignore patch). But my analysis above suggests that we have reached the limits of our ability to work around the problem.
Understood.
#908747 is 8 years old and such arguments as have been presented in favour of the current behaviour are speculative, weak, and rebutted.
I'm not sure a change in dpkg-source would help in the case where the upstream tarball (via pristine-tar) contains a .gitignore and the packaging git's HEAD doesn't?
On Sun, 13 Sep 2026 10:52:54 +0100, Ian Jackson wrote:
I presume the data in this package was made with gbp import-orig.
Right, sorry for not mentioning this.
I wasn't aware that gbp import-orig deletes .gitignore from the imported upstream git branch by default, when importing tarballs. Is that really the case?
TBH, I'm not sure if it does by default. But I've seen many packages with a debian/gbp.conf which filters out .gitignore (or more .git* stuff) for gbp-import-orig. And so does our (the Debian Perl Group's) wrapper dpt-import-orig.
It seems weird because surely the Debian maintainer generally wants the benefit of the upstream .gitignore.
I'm afraid I don't agree; personally I don't want an upstream .gitignore (which doesn't belong in a release tarball in the first place IMO) to hide files from me, when I import a tarball into _my_ packaging git repo.
So I think I am saying that maybe there is something weird in this specific package.
And many others :)But yes, the situation I keep seeing is caused by (a specific use of) gbp-import-orig and is not a bug in git-debpush. I just raised this topic because of the different behaviour from dgit-push-source.
What I found in gbp-import-orig's documentation is an option
--[no-]filter-pristine-tar
which, if I understand it correctly, also filters out the same file
from the tarball before passing (?) it the pristine-tar. I'm not sure
I like it and haven't tried it but it's there.
Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe`-
signature.asc
Description: Digital Signature
