Rebasing a branch that contains merges

Hello,

I've done some little experiments with rebasing a branch with merges on it. I wanted to check that what I found is what is intended.

I made a repository like this:

 * -- * -- * (master)
      |\
      | A (branch1) -- M (merge)
       \              /
        B (branch2) --

It's a horribly unfair thing to do, but while on merge I did

 git rebase master

I had been hoping that both branches would rebase, but only one did.  I got:

 * -- * -- * (master) -- B -- M (merge)
      |\
      | A (branch1)
       \              
        B (branch2)

"M" effectively now contains all of branch1's changes. If I hadn't referenced the merge head separately from the two branch heads, all the history in branch1 would now be represented by "M".

I don't think this is the right result.  Either
 * git should refuse to rebase because it would lose history
 * git should rebase both branches

The ideal result (perhaps unrealisticly) would have been

 * -- * -- * (master)
           |\
           | A (branch1) -- M (merge)
            \              /
             B (branch2) --

This is an unreasonable thing to expect a version control system to be able to do - it's a nasty, complicated wish. git is its own worst enemy for things like this; it's getting to be so good at nasty unreasonable things that they don't seem like fantasy-land wishes.

A perfectly valid answer is "don't be so ridiculous Andy, go away". :-)

Andy

Andy Parkins <andyparkins@gmail.com> writes:

I do not necessarily think so.  If you have this:

       o---X
      /
  ---a---o---o---o
          \       \ 
          -o---o---M---Y

it is perfectly reasonable to want to have this:

       o---X---o---o---o
      /         \       \ 
  ---a           o---o---M'--Y'

when you say "rebase --onto X a Y".

However, you have to be careful. The thing is, you do not want to 'rebase' a merge if the other branch came from somewhere not under your control. If 'a', 'o', 'X', 'Y' and 'M' are under your control, and 'x' are from somebody else's tree in the following picture:

       o---X
      /
  ---a---o---o---o
      \           \
       x---x---x---M---Y

and if you say "rebase --onto X a Y", it is not useful to rebase 'x' when you want to rewrite your history. They are somebody else's history, and other people might have got it already, too. Even if you _could_ rebase them, you would rather not.

And this is true even if 'x' are your own. You might have pushed out these 'x' to public repo although you haven't pushed out 'M', 'Y', 'o' nor 'X', and would want to rebase the still-private part to clean up the history before publishing. In such a case, you would want to end up with something like this:

       o---X---o---o---o
      /                 \
  ---a           .-------M'--Y'
      \         /
       x---x---x

This kind of rebase should be doable but you would need to tell the tool which parents of merges you would want to rebase and which ones you do not want to touch but recreate the merge by merging with your rebased branches again. In the above 'ideal', picture, three 'o's have been rebased, and then merge 'M' was recreated from the rebased rightmost 'o' and the rightmost 'x' in the original picture.

On Monday 2007 February 19 09:36, Junio C Hamano wrote:

Sorry; by "unreasonable", I meant "unreasonable to expect that your VCS is clever enough to do it". It's an offhand compliment to git; I can't imagine any other VCS is capable of this sort of thing, so the discussion wouldn't even happen.

Absolutely. We can take that as a given though can't we? That is always true for a rebase, irrespective of whether its got merges in the branch. As your diagrams show, dealing with merges during a rebase just makes things more complicated in that you can now have one parent of the merge being rebasable and one not.

My original query should have stated my assumption: that all the merged branches are mine to rebase as I see fit.

Coo; this obviously makes things much harder. What if there are further merges on the merged branches? It's going to get hard to specify which of the merge branches you want to rebase and which you don't.

So - rebase would need some sort of language to tell it which branch to favour.

 $ git checkout branch-with-merges
 $ git rebase other-branch
 rebase: Aborted because commit 123456abcdef has multiple parents:
 rebase:  - 123456789abcdef
 rebase:  - abcdef123456789
 $ git rebase --include-parent abcdef123456789 other-branch

Yuck.  I've made myself ill now.  It's not going to be pretty is it?

For now, I wanted to make git-rebase just abort if there are merge commits in the rebased branch, I had a quick look at git-rebase.sh to see if I could find the place were this could be detected and have got lost. So I've failed again :-)

At the moment, git-rev-list --no-merges is used. I don't think that, that's the correct thing to do. That just filters out the merge. Doesn't that risk loss of history as I showed in my first email?

Andy

On 2/19/07, Andy Parkins <andyparkins@gmail.com> wrote:

The more I use git, the more I start thinking that a domain-specific language to describe merges would not be a bad thing. It's so easy (painless, thought-free) to create a complex set of branches that you'd like to rearrange with each other.

Of course, perhaps the right solution is to be simpler and old fashioned and cease hyper-multitasking (i.e. shooting myself in the foot).

(I'm sharing Andy's assumption that my repo is just mine, not really shared -- add in sharing, or public use, and it gets far more complex, and the language idea might be a good idea, and not just an idea. Darcs has it's theory of patches, though it's not a language).

best, -tony

blindglobe@gmail.com Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05).