Hi,
On Sun, 24 Jun 2007, Junio C Hamano wrote:
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
