|
dc51d774
|
2018-01-21T16:50:40
|
|
merge::trees::recursive: test for virtual base building
Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.
|
|
|
b2b37077
|
2018-01-21T18:05:45
|
|
merge: reverse merge bases for recursive merge
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.
|
|
b3c0d43c
|
2018-01-22T14:44:31
|
|
merge: virtual commit should be last argument to merge-base
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.
|
|
|
3619e0f0
|
2018-01-22T23:56:22
|
|
Add failing test case for virtual commit merge base issue
|
|
|
5b9c63c3
|
2015-11-20T19:01:42
|
|
recursive merge: add a recursion limit
|
|
78859c63
|
2015-11-20T17:33:49
|
|
merge: handle conflicts in recursive base building
When building a recursive merge base, allow conflicts to occur.
Use the file (with conflict markers) as the common ancestor.
The user has already seen and dealt with this conflict by virtue
of having a criss-cross merge. If they resolved this conflict
identically in both branches, then there will be no conflict in the
result. This is the best case scenario.
If they did not resolve the conflict identically in the two branches,
then we will generate a new conflict. If the user is simply using
standard conflict output then the results will be fairly sensible.
But if the user is using a mergetool or using diff3 output, then the
common ancestor will be a conflict file (itself with diff3 output,
haha!). This is quite terrible, but it matches git's behavior.
|
|
|
34a51428
|
2015-11-09T11:55:26
|
|
merge tests: add complex recursive example
|
|
|
b1eef912
|
2015-10-27T18:00:30
|
|
merge: add recursive test with conflicting contents
|
|
|
fccad82e
|
2015-10-27T14:23:35
|
|
merge: add recursive test with three merge bases
|
|
|
99d9d9a4
|
2015-10-26T17:44:36
|
|
merge: improve test names in recursive merge tests
|
|
|
a200bcf7
|
2015-10-26T17:25:42
|
|
merge: add a third-level recursive merge
|
|
|
cdb6c1c8
|
2015-10-26T17:14:28
|
|
merge: add a second-level recursive merge
|
|
|
86c8d02c
|
2015-10-22T20:20:07
|
|
merge: add simple recursive test
Add a simple recursive test - where multiple ancestors exist and
creating a virtual merge base from them would prevent a conflict.
|