debhelper (at least in sid) has a debian/source/options with;

  tar-ignore
  tar-ignore=debhelper/.idea

And it has a .gitignore.  This has the following effects:

 1. It defeats dgit's passing of a -I and -i options to dpkg-source,
    so the dgit-generated source package does not contain .gitignore

 2. If one were to somehow manage to make a proper source package
    that corresponds to the git tree, it wouldn't round trip
    through dpkg-source.

So IMO there is no way to make a DFSG-compliant source package of
Debian's current debhelper package.

I was just assisting another DD contributor with this and other
problems; I was going to try to help sort out a mess by doing what
amounted to a sponsored upload.  However, this turned out to be
impossible.

I have done a non-dgit-based non-DFSG-compliant upload instead.

What should we do about this ?  Options (not mutually exclusive) could
include:

 * File a bug or MR against debhelper
 * Somehow ask that dpkg-source do something about this, but what ?
 * Have dgit detect this situation and at least explain it to the user
 * Have dgit generate a non-roundtrippable source package
   (probably very hard and also undesirable)

Ian.

So this is a common pattern in my packages although it sometimes appears
in d/s/local-options rather than d/s/options.

Basically, the issue is when you have something you want to have
locally, not in git and also not in the archive.  In one my other
packages, I have a "local" directory filled with local work items
(including a full copy of the sudo deb package for testing purposes).
Here the "local" directory is listed both in .gitignore and in
"tar-ignore", because I do not want it in git nor in the archive when I
do an upload.

To solve this, I add `tar-ignore=...` (for native packages) to
debian/source/(local-)options.  However, if you add that option, you end
up with the entire *.git* directory in the tarball.  To avoid that, I
add the `tar-ignore` on its own to get the sane defaults back.

This then breaks dgit leading to this bug, which is kind of a catch-22
if you want local specific things (IDE files or local prototype stuff)
that you guarantee is excluded from git and dpkg-source automatically
and also support dgit at the same time.

Best regards,
Niels

PS: Not sure if this problem is specific to native packages, which I
happen to maintain a lot of (relative to other maintainers).

PPS: Another example is debputy/experimental. In there I also included
some python related artefacts because the early drafts do not have a
proper clean rule for all the "local only" tooling I use, such as python
coverage.  The official builds do not use these things, so the clean
rule should work fine, but I do not want a left over ".coverage"
appearing in the source package as it is just cruft.

Hi.

FTR, I didn't intend to draw this bug to your attention as the
debhelper maintainer.  #1050709 was addressed to dgit maintainers
about about how to deal with this situation in dgit.

I suggested in dgit that we might do one or more of the following
(numbering addded):

| 1. File a bug or MR against debhelper
| 2. Somehow ask that dpkg-source do something about this, but what ?
| 3. Have dgit detect this situation and at least explain it to the user
| 4. Have dgit generate a non-roundtrippable source package
|    (probably very hard and also undesirable)

I am working on (3).  (4) seems wrong.  As for (2), that's already
#908742 and #908747.

Since you've engaged, let me do (1) now, and clone this bug
and address you as debhelper maintainer:

The fundamental principle of operation of dgit is that the git tree[1]
is *identical*[2] to result of dpkg-source -x.

Niels Thykier writes ("Bug#1050709: tar-ignore debian/source/options"):

dgit refuses to work with d/s/local-options, because they cannot be
included in the source package.  In debhelper it seems that someone
moved the ignores to d/s/options, probably for this reason.

That's fine.  The correct approach is to make dpkg-source and git
agree with each other.  The problem with plain tar-ignore is that it
ignores .gitignore, which *is* in your git tree and is not ignored by
git.

See https://bugs.debian.org/908747

Yes, that makes sense.

Please change this to --tar-ignore=.git.  I.e., I think,
`tar-ignore=.git` in d/s/options.

I think that will cause dpkg-source to do the right things.  I tested
this locally and it seems to fix the problem.

Patch attached.

It's somewhat worse with non-native packages because things are more
complicated and there's all the different git workflows, but the basic
issue is the same.

Thanks,
Ian.

[1] The git tree uploaded to the dgit git server and seen via "dgit
clone".  There are split view modes for handling some, but not all,
deviations from this principle, notably patches-unapplied git trees.

[2] Except that there is no .pc directory in the git tree.