2.3 KiB
.> builtins.merge
Here's the scenario that can produce bad empty namespace LCAs:
deletes of v4
j1: ... - v1 - v2 - v3 - v4 - v4a - v5 - v6 - v7
/
<empty> - v5a
adds of unrelated
j2: ... - v1 - v2 - v3 - v4 - x0 - x1 - x2 - x3
/
<empty> - z1
So j1
and j2
have common history up through v4
, then j1
deletes some definitions while j2
adds some definitions via shallow merges. These shallow merges then result in the LCA being the empty namespace rather than v4
.
First, we create some common history before a fork:
.> alias.term builtin.Nat.+ a.delete1
.> alias.term builtin.Nat.* a.delete2
.> alias.term builtin.Nat.drop a.delete3
.> alias.type builtin.Nat a.Delete4
Now we fork a2
off of a
. a
continues on, deleting the terms it added previously and then adding one unrelated term via a merge with little history. It's this short history merge which will become a bad LCA of the empty namespace.
.> fork a a2
.> delete.term.verbose a.delete1
.> delete.term.verbose a.delete2
.> delete.term.verbose a.delete3
.> delete.type.verbose a.Delete4
.> alias.term .builtin.Float.+ newbranchA.dontDelete
.> merge newbranchA a
.a> find
Meanwhile, a2
adds some other unrelated terms, some via merging in namespaces with little history. When merging a2
back into a
, the deletes from their common history should be respected.
.> alias.term builtin.Text.take a2.keep1
.> alias.term builtin.Text.take a2.keep2
.> alias.term builtin.Text.take a2.keep3
.> alias.term builtin.Text.take a2.keep4
.> alias.term builtin.Text.take a2.keep5
.> alias.term builtin.Text.take newbranchA2.keep6
.> merge newbranchA2 a2
.a2> find
.> fork a asquash
.> merge a2 a
.> squash a2 asquash
At this point, all the things that a
has deleted (delete1
, delete2
, etc) should be deleted in both the merged and squashed results. Let's verify this:
.a> find
.asquash> find
.> view a.keep1 a.keep2 a.keep3
.> view asquash.keep1 asquash.keep2 asquash.keep3
.> view a.Delete4
.> view asquash.delete1