I'm working on a re-roll of http://thread.gmane.org/gmane.comp.version-control.git/205796 and finally got around to including test cases for what you fixed in this patch. I want to make sure I'm testing what you fixed here. See questions below. On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord <hordp@xxxxxxxxx> wrote: > Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) > 'git rebase --preserve-merges' fails to preserve empty merge commits > unless --keep-empty is also specified. Merge commits should be > preserved in order to preserve the structure of the rebased graph, > even if the merge commit does not introduce changes to the parent. > > Teach rebase not to drop merge commits only because they are empty. Consider a history like # a---b---c # \ \ # d---l # \ # e # \ # C where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'. My test case runs 'git rebase -p e l' and expects the result to look like # a---b---c # \ \ # d \ # \ \ # e---l > A special case which is not handled by this change is for a merge commit > whose parents are now the same commit because all the previous different > parents have been dropped as a result of this rebase or some previous > operation. And for this case, the test case runs 'git rebase -p C l'. Is that what you meant here? Before your patch, git would just say "Nothing to do" and after your patch, we get # a---b---c # \ \ # d \ # \ \ # e \ # \ \ # C---l As you say, your patch doesn't try to handle this case, but at least the new behavior seems better. I think we would ideally want the recreated 'l' to have only 'C' as parent in this case. Does that make sense? Martin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html