Git, Debian, and upstream

I'm in the process of converting all of my software repositories to Git, but to date I've only converted either Debian packaging repositories for software I don't personally maintain or repositories for software without a corresponding Debian package. But next on my list to tackle are pam-afs-session and pam-krb5, for which I'm both packager and upstream. Currently, the upstream development is in bzr and the Debian packaging is in svk.

What I used to do, with Subversion, is keep the upstream development and Debian packaging in the same repository. I'd exclude debian/* when doing releases and then export it into an unpack of the release tarball to do Debian package builds. That worked great for me, but had some significant drawbacks: the Subversion repositories generally weren't public (I don't want to host upstream development on Alioth), and manual work is required to get the upstream tarball to use with the Debian package build.

pristine-tar, which lets you commit a tarball to a Git repository in a space-efficient manner by basing it off of an upstream branch, is awesome. It's one of the best ideas in revision control since DVCSes. Debian package builds can be done using only the information in the repository without bloating the repository with huge binary blobs. And for upstream development, I can capture in the repository exactly what I released.

However, for pristine-tar to work properly, I need to have a branch that represents the full release tarball, including the stuff that I don't want to normally track in the repository for regular development (generated files like configure that are created with make dist). I could let all that stuff be added with an xdelta, but I think that's ugly and won't be space-efficient. That means that when I combine Debian packaging and upstream development into one repository, I can't easily use the upstream development branch as the basis for the Debian packaging and pristine-tar, since it's missing all those generated files that are part of the tarball release.

I could use two separate repositories, but that makes it harder to cherry-pick upstream commits and also requires that I have two separate directories for working on the same package, which I don't like.

What I'm leaning towards doing at the moment is doing development on master, importing released tarballs into an upstream branch that shares no common commits with master, checking in the release tarballs under both the upstream release name and the Debian .orig.tar.gz name using pristine-tar based on the upstream branch, and branching a debian branch off of upstream instead of master. It's a little weird to have two separate lines of development that share no common ancestor but have the same files, but it's the solution that seems to work best for what I want and lets me store space-efficient tarballs and use git-buildpackage to do Debian builds without needing anything outside of the repository.