Skip to content

Recursive merge: reverse the order of merge bases - #4491

Merged
ethomson merged 6 commits into
masterfrom
ethomson/recursive
Feb 8, 2018
Merged

Recursive merge: reverse the order of merge bases#4491
ethomson merged 6 commits into
masterfrom
ethomson/recursive

Conversation

@ethomson

Copy link
Copy Markdown
Member

When git encounters multiple merge bases during a recursive merge of two commits, it reverses the order of the merge bases before starting the recursive merge. This was introduced in 8918b0c:

It seems to be the only sane way to do it: when a two-head merge is
done, and the merge-base and one of the two branches agree, the
merge assumes that the other branch has something new.

If we start creating virtual commits from newer merge-bases, and go
back to older merge-bases, and then merge with newer commits again,
chances are that a patch is lost, because the merge-base and the
head agree on it. Unlikely, yes, but it happened to me.

I've updated the tests, with git itself, and ensuring that we produce the same output, so many of the unit tests were changed to ensure that we created identical trees to git. With this change (along with #4488 and #4489), we now produce identical output.

I have included the changes from #4488 and #4489 here to illustrate. I suggest we review and merge those and then I will rebase this on top of the updated master.

@ethomson

Copy link
Copy Markdown
Member Author

Also, I think that we should bring this base reversal change (but not the CR/LF or conflict marker changes) to backport.

@pks-t

pks-t commented Jan 25, 2018

Copy link
Copy Markdown
Member

Had the same though, thanks for taking care of it!

ethomson and others added 6 commits February 4, 2018 10:29
Provide a simple function to reverse an oidarray.
When the commits being merged have multiple merge bases, reverse the
order when creating the virtual merge base.  This is for compatibility
with git's merge-recursive algorithm, and ensures that we build
identical trees.

Git does this to try to use older merge bases first.  Per 8918b0c:

> It seems to be the only sane way to do it: when a two-head merge is
> done, and the merge-base and one of the two branches agree, the
> merge assumes that the other branch has something new.
>
> If we start creating virtual commits from newer merge-bases, and go
> back to older merge-bases, and then merge with newer commits again,
> chances are that a patch is lost, _because_ the merge-base and the
> head agree on it. Unlikely, yes, but it happened to me.
Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.
Our virtual commit must be the last argument to merge-base: since our
algorithm pushes _both_ parents of the virtual commit, it needs to be
the last argument, since merge-base:

> Given three commits A, B and C, git merge-base A B C will compute the
> merge base between A and a hypothetical commit M

We want to calculate the merge base between the actual commit ("two")
and the virtual commit ("one") - since one actually pushes its parents
to the merge-base calculation, we need to calculate the merge base of
"two" and the parents of one.
@ethomson
ethomson merged commit d749822 into master Feb 8, 2018
@pks-t pks-t mentioned this pull request Feb 20, 2018
@ethomson
ethomson deleted the ethomson/recursive branch October 26, 2018 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants