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

[Michael Haggerty <mhagger@alum.mit.edu>]

Björn Steinbrink wrote:
> 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).

> [...]
> 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!

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