Re: rebasing merges

["SZEDER Gábor" <szeder@ira.uka.de>]

Hi,

On Tue, Sep 23, 2008 at 11:11:29AM +0200, Andreas Ericsson wrote:
> That's beside the point though, as I firmly believe git should be more
> helpful in this situation. If "git rebase -i -p" doesn't help you fix
> the problems, I'll see what I can do to help.
I will just throw in an other workflow, where keeping merges during
(non-interactive) rebase would be really helpful for me.

The DAG looks like this:

  -A--------------H    master
    \
     B--C------F--G    topic
         \    /
          D--E         subtopic

I develop a new feature in my private repository on branch 'topic'.
Every now and then there are two or more commits that somehow belong
together (e.g. a refactoring consisting of multiple commits).  I
prefer having this "belong together" information explicitly in the
repository, therefore for these commits (D and E) I create the new
branch 'subtopic' that will be merged back into 'topic' (with
--no-ff).  This way I can see in the logs or in gitk explicitly that
those commits belong together.  While working on a bigger feature
there might be multiple 'subtopic' branches that get merged back into
'topic'.

But now I can't rebase 'topic' on top of master, because rebase would
linearize the history, losing the subtopic merges.


Best,
Gábor