[git-buildpackage] Unexpected behaviour when upstream uses export-subst gitattribute

[Danny Edel]

Hello List,

I'm not sure if I operated gbp wrong or if this may even be a genuine
bug, so I hope this is the right place to ask.

Suppose the following situation:

1. upstream uses git
2. In some file (probably in a --version printing context), upstream
uses the "export-subst" gitattribute to embed the commit sha1 into the
exported file.
3. Upstream creates releases by (gpg-signing and) tagging commits.
4. Debian packaging wants to benefit from upstream git, so I create a
new branch and add the debian packaging.

Now, when I call gbp buildpackage, the build fails with:

> dpkg-source: info: local changes detected, the modified files are:
(File that uses export-subst)


Maybe I just missed a sensible option about this, please point me into
the right direction (I tried git-grep'ing the git-buildpackage source
for subst and attributes and didn't get anything useful).


For easier reproduction, I've created some minimal "working" (or, rather
"breaking") example:


Pretend upstream repo

git://github.com/dannyedel/hello-world-version.git

Pretend debian packaging repo

git://github.com/dannyedel/pkg-hello-world-version.git



My analysis so far:

The .orig.tar.gz gets created from the actual upstream revision,
embedding "d2b..." sha.

Then gbp exports the whole HEAD (not just the debian/ subdirectory) over
the unpacked orig.tar.gz, embedding the debian "639..." sha.

Since this is a non-native debian package, all debian-changes should be
in the debian/patches subdirectory, or managed with the patch-queue
system -- is there any way to tell gbp to unpack upstream, delete
debian/ directory, and use *only* the debian/ directory from HEAD,
similar to how conventional orig.tar.gz+debian.tar.xz would work?


- Danny