The lane caught up by merge, because every commit of it touches the notes

This commit is contained in:
Joseph Ferano 2026-09-20 20:06:26 +07:00
parent f8dfdaa9a0
commit f1721e650c

10
FIX.org
View File

@ -3109,9 +3109,13 @@ what was true when they were written.
operand orders, the literal rule still standing, and the shift carve-out in operand orders, the literal rule still standing, and the shift carve-out in
both directions. both directions.
- *Verified in a trial-merged tree, not only on the lane.* dev-loop moved - *Verified in a trial-merged tree, not only on the lane.* dev-loop moved
five times while this was open, so the branch was rebased onto each tip and eight times while this was open, and the acceptance rows, the full suite and
the acceptance rows, the full suite and the sweep were re-run against the the sweep were re-run against the last of them. The branch caught up by
last one. The merge into dev-loop is a fast-forward with no conflicts. rebase until the notes file made that expensive — every commit of this lane
touches FIX.org and so conflicted with every landing that also did — and
finishes with an ordinary merge of dev-loop into the lane instead, resolved
once. The merge back into dev-loop is clean, and was built, run and tested
as a merged tree rather than only on the branch.
- *The corpus sweep, base against lane.* Headless programs (test/programs/) - *The corpus sweep, base against lane.* Headless programs (test/programs/)
were compiled, ~check~ed and run, and the diff of the whole lot is a single were compiled, ~check~ed and run, and the diff of the whole lot is a single
pure addition: widening.flan's own rows. Not one existing program's pure addition: widening.flan's own rows. Not one existing program's