How to do a real "rebase instead of merge" from the SourceTree merge dialog?

[Chris Marlowe]

We're trying to avoid introducing extraneous merge commits when merging simple (single commit) topic branches back into the master branch. In many cases, that happens automatically using fast-forward. But if another commit was added to master after the branch point, it must be accomplished by first rebasing onto the last master commit and then performing a (fast-forward) merge. This can be a bit tedious since it takes four steps: 1) checkout the topic branch, 2) do the rebase, 3) checkout master, 4) do the merge.

So, when I first saw the "rebase instead of merge" checkbox in the merge dialog I thought "How wonderful, SourceTree will do this for me so I can just stay on the master branch and do this in a single operation." But instead, that option appears to rebase the new string of commits on the master branch onto the end of the topic branch which seems totally counter-intuitive (why would you even want to do that?). What's more, you must still do the fast-forward merge as a separate step so there is no real convenience over just doing a rebase and merge as separate steps.

So my question is, is there some trick in SourceTree that streamlines this (probably common) rebase/merge operation? If not, I wonder if there's any hope it might be added in the future? BTW, I'm using the Windows version 1.5.2 of SourceTree.

[Chris Marlowe]

Thanks, Seth, for your input. (With so much karma, you've obviously done a lot of thinking and discussion about Git/SourceTree -- I'm relatively new to it.) I'm currently drawing up guidelines for the rest of my team in an attempt to reduce unnecessary history clutter and was hoping to find a one or two step solution to this scenario to keep it simple.

I don't see this as a Git limitation, though. SourceTree operations routinely involve several Git commands performed in sequence (don't they?), hence my optimism when I saw the "rebase instead of merge" box in the Merge dialog and assumed the semantics of the Merge would still apply. But I guess performing a git-checkout multiple times, which is what it would take, might be too complicated or risky to combine in a single SourceTree operation.

This probably does qualify more as a feature request. Maybe I'll submit one.

[Seth]

Ah, I see. That is odd. That approach works well when doing a pull-rebase (which merges the remote branch to the checked-out local branch), because in that case you want to maintain the integrity of the remote branch.

Method (5) would require one less step if the person who committed C (who already has topic checked out) performed the merge-rebase with master.

Otherwise, this seems like a Git limitation, not a SourceTree limitation, unless you can define a Git command that will acheive scenario (3). If you ARE able to define such a command, include it in a feature request.

[Chris Marlowe]

No I'm not trying to squash any commits. Maybe a picture will help me explain. Starting from (1) with master checked out (bold), a normal merge of the topic branch into master will result in (2). But I would like to do a rebase of the topic branch onto master instead of a merge into master to obtain (3). However, when I check the "rebase instead of merge" box in the Merge dialog, I get (4) which is a rebase of master onto the topic branch. This is not desirable, as I'd rather not be changing the commits already on the master branch. If any of them have already been pushed to the remote repo, we'll end up with a side branch containing duplicate commits, the kind of thing I'm trying to avoid by doing the rebase.

I suppose I could checkout the topic branch instead, in (1), and then merge the master into it with the rebase option checked to get (5) but then I'd have to checkout master again and do a fast-forward merge to get (3). But that doesn't save any steps -- I may as well just do a rebase explicitly.

[Chris Marlowe]

 (1) (2) (3) (4) (5)                                   [topic]                    [topic]
     [master]               [master]                [master]                [master]          [master]
          |                           |                            |                           |                      |
---A---B           ---A---B---D           ---A---B---C'           ---A---C---B'           ---A---B---C'
     \                     \         /                                                    |                                  |
      C                     --C--                                                   [topic]                           [topic]
       |
    [topic]

No I'm not trying to squash any commits. Maybe a picture will help me explain. Starting from (1) with master checked out (bold), a normal merge of the topic branch into master will result in (2). But I would like to do a rebase of the topic branch onto master instead of a merge into master to obtain (3). However, when I check the "rebase instead of merge" box in the Merge dialog, I get (4) which is a rebase of master onto the topic branch. This is not desirable, as I'd rather not be changing the commits already on the master branch. If any of them have already been pushed to the remote repo, we'll end up with a side branch containing duplicate commits, the kind of thing I'm trying to avoid by doing the rebase.

I suppose I could checkout the topic branch instead, in (1), and then merge the master into it with the rebase option checked to get (5) but then I'd have to checkout master again and do a fast-forward merge to get (3). But that doesn't save any steps -- I may as well just do a rebase explicitly.

[Seth]

So it sounds like you want your rebase to squash the commits from the topic branch into one commit, correct? If that isn't correct, I'm not sure why the "rebase instead of merge" behavior you described isn't what you're looking for.