Re: rebasing merges

From: SZEDER Gábor <szeder@ira.uka.de>
Date: Sep 23, 2008, 11:16 UTC
Message-ID: <20080923111624.GA20259@neumann>
In-Reply-To: <48D8B2C1.5070800@op5.se>

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