diff --git a/docs/admiralty-fleet-repo.md b/docs/admiralty-fleet-repo.md index ea6fb0ca2b..f3df1a76d3 100644 --- a/docs/admiralty-fleet-repo.md +++ b/docs/admiralty-fleet-repo.md @@ -33,8 +33,8 @@ vessel: updated e52cc76..492361e FF_STATUS=updated ``` -This fork's `main` has since advanced past `e52cc76`, so its tip is no longer an ancestor of `492361e`; it stood at `ce43899` when this document was written. -A vessel sitting at the fork's current `main` and pointed at `admiralty`'s `main` would therefore hit exactly the refused advance described above, and how that is repaired before cutover is still open; see "What is not built yet". +This fork's `main` has since advanced past `e52cc76`, so its tip stopped being an ancestor of the original `admiralty` tip. +Measured again on 2026-08-05 UTC, `admiralty` has absorbed history through the newer pin `b5c0bf6`, but this fork's `origin/main` had already advanced 36 commits past that pin again; see "What is not built yet" for why each later pin bump needs the same ancestry repair. ## The shape of the repository @@ -154,9 +154,13 @@ None of that means the canonical upstream template absorbed those patches: the v Ancestry is a property of the commit graph and not of tree content, so a pin bump alone does not restore it: a bump commit on `admiralty` copies the fork's newer tree, but it does not add the fork's newer commits to `admiralty`'s ancestor set. Absorbing that history so an already-updated vessel stays fast-forwardable needs a true merge of the fork's `main` into `admiralty`'s `main`, which is consistent with the standing rule that upstream-sync pull requests land as true merge commits rather than squashes. How such a merge interacts with the drift gate is no longer the open part: `admiralty`'s own `fleet/doctrine/pin-and-bump.md` owns the merge-bump procedure, including regenerating the manifest in that same commit and the verification to put in the pull request. - What remains open is that the procedure has not been applied. - The 2026-08-01 pin bump to `de0b95b` landed as an ordinary single-parent commit rather than a merge, so it copied the tree without absorbing the history, and even a vessel sitting exactly at the current pin cannot fast-forward onto `admiralty`. - Measured on 2026-08-01 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `285289c24be625f5b27d5ae846dd09024114534c`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor de0b95b7a13e72256089707aeab6aac83d00e90d 285289c24be625f5b27d5ae846dd09024114534c` exits 1, and the newest fork commit that is still an ancestor of that `admiralty` `main` is `bbf0023` of 2026-07-30. - Name the `admiralty` commit rather than a bare `origin/main`, because in this repository `origin/main` is the fork itself, where `de0b95b` is an ancestor and the same command exits 0. - That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so it is authorized on the captain's word instead. + **The procedure has since been applied.** + `admiralty`'s `chore(pin): bump vendored firstmate to b5c0bf6` (commit `4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b`, 2026-08-04) lands as a true merge: its second parent is this fork's `b5c0bf65d43ca274e8f8ae3b700426d614e7585c`, so `admiralty`'s ancestor set now includes the fork's history up to that commit, not just its tree. + A vessel sitting exactly at that pin can now fast-forward onto `admiralty`. + Measured on 2026-08-05 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `d16bf0cd19c316376f77615f46fd0e8e85fde45a`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a` exits 0. + Name the `admiralty` commit rather than a bare `origin/main`, because inside that clone `origin` is `admiralty`, while in this repository `origin` is the fork; the same command against the wrong side answers a different question. + The newest fork commit that is an ancestor of that `admiralty` `main` is the pin itself, `b5c0bf6`, dated 2026-08-04: the merge absorbed the fork's history exactly up to the commit it pinned, no further. + This fork's `main` has since advanced past the pin again: in this same review pass, `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c origin/main` exits 0 and `git rev-list --count b5c0bf65d43ca274e8f8ae3b700426d614e7585c..origin/main` reports 36 commits. + The same open question - restoring ancestry as the fork keeps moving - recurs at every pin bump, and each one needs its own merge, not just the first. + That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so each one is authorized on the captain's word instead. - The Bridge extraction, the fork-maintenance tooling retirement, and the Bucket-A upstreaming are unstarted; the fork-first ratchet prices each as its own reviewed pin bump.