Re: [PATCH 2/2] Teach rebase an interactive mode

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 24, 2007, 14:33 UTC
Message-ID: <Pine.LNX.4.64.0706241533030.4059@racer.site>
In-Reply-To: <7v4pkxydim.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sun, 24 Jun 2007, Junio C Hamano wrote:

Show 31 quoted lines

> This is just an idea, but I have been wondering if it would be useful if 
> we teach rebase (interactive or not) to handle a merge from an unrelated 
> (wrt the rebase that is being performed) branch.  That is, if you had 
> this development on top of the origin 'O':
> 
>              X
>               \  
>            A---M---B     
>           /
>   ---o---O
> 
> that you committed A, merged X and then committed B, you should
> be able to rebase on top of an updated upstream 'Q':
> 
>              X
>               \  
>            A---M---B     
>           /
>   ---o---O---P---Q
> 
> by 'pick A/merge M/pick B', which would do:
> 
>                      X
>                       \
>                    A'--M'--B'
>                   /
>   ---o---O---P---Q
> 
> Note that A', M' and B' are different commit objects (rebase
> rewrites the history) from the original picture, but X is the
> same commit from the original picture.

Yes, I think that would be useful. But at the same time, I think it should not be the default. Why? Because I will use rebase to beautify my history, and that looks mostly like this:

--- A - B - C - D - E - junio/master
      \       \   \
        M - N - O - P - my

So what I want is really clean up my side branch.

Therefore I would like to have this --preserve-merges (short option -p?) _after_ rebase -i.

It will get a little tricky with different merge strategies, and saying which commits have to be rebased (A in your example), and which will be preserved (X in your example), and evil merges (merges which have fix ups in addition to the merge), but doable.

Ciao, Dscho