publishing a forked^W cloned directory with ancestry

[martin f krafft]

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.

-- 
"if builders built buildings the way
 programmers wrote programs,
 then the first woodpecker that came along
 would destroy civilization."
                                                  -- gerald weinberg
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20070830/b2c4e5f5/attachment.pgp