jschoubben
c87a4421b9
mesh/merge-gate pass: builds gitea → novox; no bus step; every machine composes with the change as it did without (4 of 4 compose)
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery delivered
The second review found the gap it was asked to look for: everything after the forge's merge could throw — a forge 5xx, a timeout, a commit named without parents — and the caller got a bare error that never said the merge had happened. From the merge on, a read-back that fails or cannot be done is said beside merged: true, in read_back; only a proven other head is an error, and that error says the merge happened. A parent named without its sha is a failed read-back, never an empty head said to have landed. A fast-forward's commit is taken as the head only when the forge names it so. That it does is assumed, not seen on this forge, so another sha is said in read_back rather than raised as another head having landed. The method's description lists all five methods and says which two can be read back. The fast-forward test now gives the merge commit a different second parent, so reading it as a merge would fail there.