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

Junio, thanks for the response.  I am finally getting around to
following up.

On Wed, 2008-01-02 at 14:12 -0800, Junio C Hamano wrote: 

quoted

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.

I take this to mean a situation like this:

 * There is a series of patch X Y Z that implements some nicety
   not present in the mainline yet.  This set applies to older
   codebase at point A.

 * Newer codebase B does things differently from codebase A and
   patch X is no longer needed --- IOW, what X achieves on top
   of A has already been incorporated somewhere between A and B.
   Applying Y and Z suffices to obtain that nice feature on top
   of B.

Actually, I was thinking of a change to the mainline that causes a
conflict with the patch series.  For example, my repository of git was
at point A when I made the first draft X of my "gitweb: snapshot
cleanups & support for offering multiple formats" change.  Then I
updated my repository and got commit B, "gitweb.perl - Optionally send
archives as .zip files", among others.  When I rebased X on top of the
new master C, there was a conflict, which I resolved to produce X':

     X                   X'
    /                   /
---A---...---B---...---C

But now, with refs only to C and X', I have lost the information that
the previous incarnation of X' was X.

Essentially, my objection to rebasing is that I want to keep a history
for the patch series containing all of the patched versions that I have
released (here X and X'), especially when they differ in interesting
ways (i.e., conflict resolutions), and this history should be a
first-class object that others can pull from me via the git remote
system.

I only want to use a separate patch management tool if it is integrated
with git.  I have some familiarity with StGIT, and I assume guilt is
similar.  StGIT uses rebasing and keeps an additional "patch changelog"
viewable by "stg log" which might seem to be what I want.  The trouble
is that this changelog behaves more like a reflog than an orderly
history, and "stg refresh" does not support storing a user-entered
message describing *the change to the patch* in the patch changelog.
One option I am considering is to use StGIT and track some subset of the
StGIT area itself (.git/patches) in git.

The other approach is to maintain the feature patches/branches by
merging instead of rebasing.  This has two significant advantages: patch
history is naturally kept and the full power of git's distributed merge
is available.  However, it also has two significant disadvantages: the
complaint by Linus about "useless merges" mentioned in the git-rerere
manpage applies, and it's impossible to fully revert a merge (the
ancestry remains and will cause trouble if the merge is redone later).

Matt