How to structure a project distributed with varyingly interdependent feature branches?

[Matt McCutchen <matt@mattmccutchen.net>]

Dear git people,

The rsync source repository has recently been migrated from CVS to git
at my encouragement ( http://git.samba.org/rsync.git/ ), and I am trying
to figure out a better way to structure the repository (to propose to
the maintainer, Wayne Davison, or to use myself).

Rsync presents a unique challenge because it has a number of long-term
feature patches that are maintained and distributed with the main source
code.  Furthermore, some of the patches depend on other patches.  With
CVS, the patch files were just stored in the repository; this worked,
but browsing and developing the branched versions represented by the
patches required a lot of extra work.  My hope now is to represent these
branches and their dependencies properly in git so that the git tools
handle them with the same elegance with which they handle everything
else.

The feature branches seem to present two fundamental problems:

1. How to properly represent the history of an individual branch and
update it when the trunk (or the branch on which it depends) changes.
Right now, Wayne updates the branch by rebasing; unfortunately, if the
trunk changes in such a way that one of the intermediate commits no
longer makes sense, it is impossible to update the branch while
preserving a record that the intermediate commit once existed.  Merging
gives the right history and is very well-supported by the git tools, but
it has one fatal flaw: when a dependency on another branch is removed,
there is no way to undo the merge of the other branch.  One can revert
the tree changes, but the other branch is still present in the ancestry,
which causes problems if the dependency is added again.  It seems to me
that overcoming this flaw would require significant changes to git.  Is
there some other workflow that does what is needed?  Ideally "git blame"
would work correctly.

2. How to manage the large number of branches in a practical way.  The
branch dependency information should be pullable from the main
repository to minimize the need for each developer to configure his/her
repository manually on initial cloning and when dependencies change.
Also, for an rsync release, it should be possible to tag the trunk and
all branches as a unit so that developers can ask questions like "which
branches changed between these two pre-releases?".  My feeling is that
the solution will involve a taggable, pullable master tree object that
contains the trunk and branches as submodules and also some
metainformation (including the dependencies).  However, special scripts
will then be needed to conveniently check out and update the submodules
using a single rsync source/build tree.

I'm sure the rsync project could make do without a fully general
solution for the feature branches, but it would be awesome (and a
testament to git's flexibility) if one existed.  Also, Linux
distributions maintain packages with evolving and potentially
interdependent packages, and a good solution would make it possible for
them to do all their package maintenance and patching with git.  Ubuntu
[1] and Fedora [2] are thinking about this.  From my perspective, such a
setup would make modifying distribution packages much less painful.

[1] https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl
[2] http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=38716&start=0#forumpost175743

I would appreciate any ideas toward a solution.

I am not subscribed to the list (I once was but the traffic overwhelmed
me), so please be sure to CC me in replies.

Matt