2.1 KiB
Behaviour of namespace histories during a merge.
Note: This is a descriptive test meant to capture the current behaviour of branch histories during a merge. It isn't prescriptive about how merges should work with respect to child branches, but I think we should at least notice if we change things by accident.
Setting up some history
.> builtins.merge
parent.top = "top"
parent.child.thing = "parent.child.thing"
The child branch has a single history node representing the addition of parent.child.thing
.
.> add
.> history parent.child
If we add another thing to the child namespace it should add another history node to both the child and parent.
parent.child.thing2 = "parent.child.thing2"
.> add
.> history parent
.> history parent.child
Forking off some history on a separate branch
Now we fork the parent namespace to make some changes.
.> fork parent parent_fork
parent_fork.child.thing3 = "parent_fork.child.thing3"
The child should have a new history node after adding thing3
.> add
.> history parent_fork.child
Saving our parent state
Split off two separate forks, one for testing squash merges, one for standard merges.
.> fork parent parent_squash_base
.> fork parent parent_merge_base
Squash merge
For a squash merge, when I squash-merge back into parent, we expect parent_fork.child.thing3
to be added.
.> merge.squash parent_fork parent_squash_base
.> history parent_squash_base
Notice that with the current behaviour, the history of parent.child
is completely wiped out, containing nothing from the source OR destination.
.> history parent.child
.> history parent_fork.child
.> history parent_squash_base.child
Standard merge
For a standard merge, if I merge back into parent, we expect parent_fork.child.thing3
to be added.
.> merge parent_fork parent_merge_base
.> history parent_merge_base
Child histories should also be merged.
.> history parent.child
.> history parent_fork.child
.> history parent_merge_base.child