What to do with .git directories in source package uploads?

[Nish Aravamudan]

Ian,

I noticed today that our Ubuntu git importer failed to import
src:nplan (which is only in Ubuntu). This is because the upload
(incorrectly) includes a .git directory. I see that dgit's behavior
for the same DSC file with `dgit import-dsc` is to delete the .git
directory from the source package before import. Is that a reflection
of Debian policy?

What I am hoping we can agree on is one of the two (it seems like)
options for handling .git directories. While it does seem that one can
trick git into representing .git in the treeish(s), `git push` will
fail and it just sort of conflicts with the notion of git-based
tooling, so I think actually having them in the source package treeish
is a non-starter.

The alternatives Robie and I devised are:

1) What dgit currently does, which is remove .git directories from
source packages, with a warning. This does mean that an imported
object does not match an uploaded exactly. Perhaps this is OK, but for
instance, in the case of nplan (purely as an example), if a developer
were to then use our git repository to develop a follow-on change, the
resulting debdiff would include (surprisingly to the end-user) a
removal of .git/)

2) In order from longest to shortest:
        Change any file in the source package matching ^\(\.+git\)$ to
             \.\1
        [essentially prefixing a '.' to any file consisting of only
leading '.' and the string 'git' ]

The idea here is that while we can't save the .git directory as-is, we
can losslessly convert the name (which might collide with other files,
so we must rename anything in that 'namespace'). This won't help
`dpkg-buildpackage` users, but if using our tooling, we can catch this
and rename files back before building with a conversion, in order from
shortest to longest:
        ^\.\(.+git\)$ -> \1

I'm wondering, are there are any explicit policy statements that say a
build system cannot rely on a git directory being present? Say a
debian/rules that does a `git describe`? I don't want to break such a
source package if it does exist.

I'm planning on implementing 2), as it leaves us the most wiggle-room
and we haven't asserted anything about hash stability yet in our
imports. But I'd love for some input on why 1) was chosen, and, as I
mentioned earlier, if it's considered 'policy' or not.

Let me know if I can clarify anything here!

-Nish