Re: [PATCH] rebase --preserve-merges keeps empty merge commits

From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Feb 1, 2013, 19:15 UTC
Message-ID: <CANiSa6gM1gpj0A6PC0qNVSaWvVrOBnSnjn2uKR9-cHSLAZ2OVA@mail.gmail.com>
In-Reply-To: <1358023561-26773-1-git-send-email-hordp@cisco.com>

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

Show 7 quoted lines

> 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