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 _______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss