{"thread":{"id":"32569","subject":"Failure and unhelpful error message from 'rebase --preserve-merges'","startedAt":"2013-01-09T13:19:40Z","lastAt":"2013-01-09T13:19:40Z","messageCount":1,"participants":["Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"206379","messageId":"50ED6E6C.5020400@cisco.com","threadId":"32569","inReplyTo":"50ED63CB.7060108@cisco.com","subject":"Failure and unhelpful error message from 'rebase --preserve-merges'","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2013-01-09T13:19:40Z","receivedAt":"2013-01-09T13:19:40Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"Since 90e1818f9a  (git-rebase: add keep_empty flag, 2012-04-20)\n'git rebase --preserve-merges' fails in a case where it used to\nsucceed, and it does so with an unhelpful error message.\n\n   $ git rebase --preserve-merges master\n   error: Commit 452524... is a merge but no -m option was given.\n   fatal: cherry-pick failed\n   Could not pick 452524f925aecd0439ae5728fca3887292114dd7\n\nI also tried rebase with '-m'\n   $ git rebase --preserve-merges -m master\nbut that also failed.\n\nThe same commands worked fine for these same commits in v1.7.9\n\n>From 90e1818f9a I figured out that the rebase-interactive\nmachinery had dropped one of my merges. I normally would not\nnotice this when using 'git rebase -p' since it does not invoke $EDITOR\nby default; but I can see it if I use this:\n\n   git -c sequence.editor=cat rebase -p master\n\nWith that I see my list of commits, including these:\n\n  ...\n  pick 184ec4d WIP: DHCP datastore reporting\n  # pick 16ca56c Merge ptss into sock-threads\n  pick 06aea55 WIP: More work normalizing config handlers\n  ...\n  pick 452524f Merge branch 'ptss' into sock-threads\n  ...\n  #\n  # Note that empty commits are commented out\n\nThe failure points to the 2nd merge commit, but it is not the merge\ncommit which was commented out. It is a later merge between the same two\nbranches. I'm not sure how this is related, yet.\n\nBut I now know I can work around the problem with this:\n\n    git rebase --keep-empty -p master\n\nI see three problems here, but I don't have any time to go fix them\nmyself right now.\n\n 1. 'rebase -p' should default to --keep-empty since the user will not\n    be given the opportunity to edit the list to uncomment the missing\n    commits.\n\n 2. 'rebase --interactive -p' should not drop empty merge commits.\n\n 3. rebase should not die with a cryptic cherry-pick error message,\n    although I am not sure what useful thing it could say in this\n    particular case. Maybe there are other conditions which will cause\n    this same failure even if 1 and 2 are fixed.\n\nPhil\n"}]}