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

[Matt McCutchen <matt@mattmccutchen.net>]

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: 
> > 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