Re: rebase-with-history -- a technique for rebasing without trashing your repo history

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Aug 14, 2009, 21:21 UTC
Message-ID: <4A85D53D.9050805@alum.mit.edu>
In-Reply-To: <20090813233027.GA19833@atjola.homenet>

Björn Steinbrink wrote:

Show 6 quoted lines

> On 2009.08.14 00:39:48 +0200, Michael Haggerty wrote:
>> Björn Steinbrink wrote:
>>> On 2009.08.13 14:46:07 +0200, Michael Haggerty wrote:
>>> And even for just continously forward porting a series of commits, a
>>> common case might be that upstream applied some patches, but not all.
>>> Can you deal with that?

[A discussion of various unsatisfactory approaches omitted...]

> But that's obviously total crap.

So I think we agree that it is not possible to retain history for a case like this (which is essentially a general cherry-pick).

Show 20 quoted lines

> [...]
> Doing a plain "git rebase subsystem topic" would of course also try to
> rebase the "o" commits, so that problematic. Instead, you do:
> 
> git rebase --onto subsystem O topic
> 
> That turns O..topic (the * commits) into patches, and applies them on
> top of O'. So the "o" commits aren't to be rebased.
> 
> And that's exactly what your rebase-with-history would do as well. Just
> that O is naturally a common ancestor of subsystem and topic, and so
> just using "git rebase-w-h subsystem topic" would be enough. Conflicts
> etc. should be 100% the same.
> 
> If you know that your upstream is going to rebase/rewrite history, you
> can tag (or otherwise mark) the current branching point of your branch,
> so you can easily specify it for the --onto rebase. IOW: This is
> primarily a social problem (tell your downstream that you rebase this or
> that branch), but having built-in support to store the branching point
> for rebasing _might_ be worth a thought.

Recording branch points manually, coordinating merges via email -- OMG you are giving me flashbacks of CVS ;-)

*Of course* you can get around all of these problems if you put the burden of bookkeeping on the user. The whole point of rebase-with-history is to have the VCS handle it automatically!

Show 8 quoted lines

>> and merging in a topic branch makes it more difficult to create an
>> easily-reviewable patch series.  rebase-with-history has neither of
>> these problems.
> 
> Sure, merging is a no-go if you submit patches by email (or other,
> similar means). But you compared that to an "enhanced" rebase approach,
> instead of comparing your rebase approach to the currently available
> one.

In [1] I compared rebase-with-history with both of the currently-available options (rebase and merge). Rebase and merge can each deal with some of the issues that come up, but each one falls flat on others. I believe that rebase-with-history has the advantages of both.

The example in [2] was taken straight from the git-rebase man page [3]; I did not want to claim that current practice would use merging in this situation, but rather just to show that rebase-with-history removes the pain from this well-known example.

I think we are mostly in agreement. Rebase-with-history is obviously not an earth-shattering revolution in DVCS technology, but my hope is that it could unobtrusively assist with a few minor pain points.

Michael

[1] http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html [2] http://softwareswirl.blogspot.com/2009/08/upstream-rebase-just-works-if-history.html [3] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html