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

From: Matt McCutchen <matt@mattmccutchen.net>
Date: Jan 15, 2008, 19:02 UTC
Message-ID: <1200423728.3865.69.camel@localhost>
In-Reply-To: <7vwsqrvpur.fsf@gitster.siamese.dyndns.org>

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:

Show 18 quoted lines

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