I'm working on a re-roll of


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 <ho...@cisco.com> 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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to