git rebase --preserve-merges seems to not work

  In order to push changes to our master branch, one has to have pulled 
first.  We pull with the --rebase option.  It works great except for 
merge commits.

I discovered 'git rebase' has a --preserve-merges option. I assumed it would allow me to rebase my merge commit on top of others' changes pushed to our central master branch.

Unfortunately, I can't seem to make it work. Does anyone have thoughts on what I'm doing wrong?

My session is below.

Thanks!

Josh

$ git init

$ echo a > a $ git add a $ git commit -m a $ git tag a

$ echo b > b $ git add b $ git commit -m b

$ echo c > c $ git add c $ git commit -m c $ git tag c

# Note the hierarchy is simple: a <- b <- c
$ git lg --all
* d132c87 - (c) c
* 4a88fd1 - b
* b576660 - (a) a

# Create the hierarchy: a <- d
$ git checkout a
Note: checking out 'a'.

$ echo d > d $ git add d $ git commit -m d $ git tag d

$ git lg --all
* 6abf527 - (HEAD, d) d
| * d132c87 - (c) c
| * 4a88fd1 - b
|/
* b576660 - (a) a

# Wanting to merge my branch back to my local master to push to the server.
$ git checkout a
$ git merge --no-ff c
Merge made by recursive.
  b |    1 +
  c |    1 +
  2 files changed, 2 insertions(+), 0 deletions(-)
  create mode 100644 b
  create mode 100644 c
$ git tag bc-merge

# Commit 'd' is something I would pull --rebase from the server before I 
push.
$ git lg --all
*   472fd93 - (HEAD, bc-merge) Merge commit 'c' into HEAD (3 seconds ago)
|\
| * d132c87 - (c) c (2 minutes ago)
| * 4a88fd1 - b (2 minutes ago)
|/
| * 6abf527 - (d) d (2 minutes ago)
|/
* b576660 - (a, master) a (3 minutes ago)

# Here is the rebase with the --preserve-merges option. $ git rebase --preserve-merges d Rebasing (n/3) Successfully rebased and updated detached HEAD.

# Of course, bc-merge is an orphaned branch.  Its changes got replayed 
on top of 'd'.
# Note the merge commit with the description "Merge commit 'c' into 
HEAD" is missing.
$ git lg --all
* 2c93a8a - (HEAD) c (11 seconds ago)
* 2b98bc6 - b (11 seconds ago)
* 6abf527 - (d) d (3 minutes ago)
| *   472fd93 - (bc-merge) Merge commit 'c' into HEAD (74 seconds ago)
| |\
|/ /
| * d132c87 - (c) c (3 minutes ago)
| * 4a88fd1 - b (3 minutes ago)
|/
* b576660 - (a, master) a (4 minutes ago)

On 2010.09.08 23:17:39 -0600, Joshua Jensen wrote:

Yup, and the "problem" is, that both sides of the merge got replayed.

Because the merge could be resolved as a fast-forward, as it merges the replayed commits b' and c', not the originals.

What you actually wanted to replay is just the first-parent history, redoing the merges with their respective original second parent. Jonathan (Cc'ed) had the same problem about a month ago.

The "first parent" thing isn't that well defined, criss-cross merges combined with some unfortunate fast-forwards will easily make the first-parent history become the one that you didn't mean (ask any git-svn users that dared to use "git merge" without fully understanding how git-svn uses the history ;-)), but it works in this special case. And with that special case in mind (and admittedly probably not thinking much further) I came up with this patch a few years ago:

http://marc.info/?l=git&m=119379735525213&w=2

It was not my itch to scratch though, so I never got around to get it included, and of course it doesn't apply cleanly anymore. I tried to give some hints to Jonathan ("hachi") on #git on how to update the patch to make it apply again:

http://colabti.de/irclogger/irclogger_log/git?date=2010-08-20#l1241

Feel free to pick up from there...

Björn

  ----- Original Message -----
From: Björn Steinbrink
Date: 9/8/2010 11:51 PM

I hand merged your change in to my Git installation. There is one part of git-rebase--interactive that looks entirely different, so I would need to look back through the history to determine how to properly apply it.

The good news is the patch does exactly what I want in this simple case. I will have to try it on some more complicated hierarchies to see what the end result is.

It's curious... whenever I ask around about issue X or feature Y, a previously submitted patch can generally be found in the list archives. :)

Josh