publishing a forked^W cloned directory with ancestry

Dear list,

I am the mdadm (software RAID management) maintainer for Debian and a recent git convert. While preparing a new mdadm package tonight, I found myself screaming too often at SVN [0] and decided to convert Debian mdadm package maintenance to git. Upstream also uses git, so I said to myself "jolly good", clapped hands, and… froze as the pieces weren't fitting together nicely, at least from my understanding of how git works.

There are multiple ways to maintain a Debian package and I shall today only concentrate on tracking an upstream VCS repo and packaging it for Debian "when I please" (others call that snapshotting). Thus, I don't wait for upstream to publish tarballs, I make the package from a given HEAD. There are pros and cons to this, but let's just assume that it's "the way".

So I clone upstream and find that git-branch -r includes upstream/master (s/origin/upstream/ for clarity). I then branch 'debian' off upstream/master and make some required changes. With utter enjoyment of git, I wrap it up and package a new mdadm.deb. Yay.

And then I wonder: how do I now publish this result of my work? I'd like to push my repository to git.debian.org so that others can clone it and help or submit patches against the debianised upstream.

But the remote branch upstream/master only really exists in $GIT_DIR, which is local and can't be pushed. Or well, even if I tried, the people cloning from the push location wouldn't see it [1].

I saw two solutions to this: using two separate upstreams/origins, and submodules:

1. I could tell my $GIT_DIR/config that upstream/* comes from mdadm
upstream and debian/* comes from git.debian.org and then merge
happily across branches locally and be done with it. However, John
Doe, who on a rainy Saturday afternoon has two hours to spend and
wants to fix some mdadm bugs would have to jump through hoops to
replicate the setup: all the ties between upstream and the
git.debian.org repo are local to my machine and can't be pushed
anywhere (except to verbose documentation).

2. Let's assume for a moment that all Debian changes go to ./debian,
then submodules seem to want to save the day. Except that Debian
changes are not confined to ./debian, and from the perspective of
the Debian mdadm maintainer and with the semantics of git-submodules
in the back of my head [2], I'd rather want it the other way around:
upstream be a submodule of my Debian-specific repo; but upstream
needs to live in . and TTBOMK, submodules can't live in .

So neither of these work and thus I am turning to you. I want to publish my Debian "fork" of mdadm in such a way that people can easily clone it, without pulling all the components together. How would you do it?

I guess the cleanest solution I can come up with is to branch off upstream/master into branch "upstream" whenever *I* decide it's time to snapshot. Then, people using my repo would basically be confined to the state of the tree as it was the last time I rebased "upstream", but could work freely on the Debian-specific stuff. I think this is actually quite okay, but I am still interested in any comments you may have.

Cheers, m

Footnotes:

[0] fine "too often" tonight meant "once" but it's once too many.
    Thanks Linus and Junio, since I touched git I can't work most
    other VCS anymore (this is sarcastic... not).
[1] I tried cloning B from A, then cloning C from B. Within C, there
    is no reference to A's master branch, so unless B pulled changes
    from A and C pulled changes from B, C could not be updated.
[2] The submodule's commit ID is stored in the supermodules index
    and a commit to the submodule also requires a commit to the
    supermodule to restore consistency.