@@ -62,11 +62,10 @@ question and **warns** — it does not refuse:
6262* ** Not on ` origin/main ` ** — a loud warning naming the branch(es) the commit * is*
6363 on, and saying which situation it is: pushed onto a branch that never merged, or
6464 never pushed at all. The pin is still written; deciding is yours.
65- * ** Cannot be answered** — no ` origin/main ` in the checkout, or the commit object
66- is absent — it says * that* , and never borrows the wording of either verdict.
67- (` git merge-base --is-ancestor ` exits ** 128** on an absent object: an error, not
68- a "no". And ` git rev-parse HEAD ` exits 0 for a commit whose object is missing,
69- so the pin arriving is no proof the object is there.)
65+ * ** Cannot be answered** — no ` origin/main ` in the checkout — it says * that* , and
66+ never borrows the wording of either verdict. (` git merge-base --is-ancestor `
67+ exits ** 128** rather than returning a verdict when it cannot read an object: an
68+ error, not a "no".)
7069
7170It is a warning rather than a gate on purpose: ` origin/main ` is only as fresh as
7271your last fetch, so a hard failure here would reject a legitimately-just-merged
@@ -78,6 +77,37 @@ though, a bad pin merges and `pnpm sdui:manifest` below would ratchet
7877spec↔registry parity against a tree that is not on main — which is why the
7978producer half warns at all.
8079
80+ #### A commit object it cannot read is refused, not warned about (#10797 )
81+
82+ The bullets above are about a pin that is not on ` main ` — a real commit you can
83+ still meaningfully pin. A pin whose commit ** object cannot be read at all** is a
84+ different thing: there is nothing to pin, and no changeset entry or commit message
85+ can be derived from it. That refuses, and it refuses ** before writing anything** :
86+
87+ ```
88+ ✗ REFUSING to bump: the objectui commit object <short> cannot be read in <path>.
89+ …
90+ NOTHING WAS WRITTEN — .objectui-sha is untouched and still holds the old pin.
91+ ```
92+
93+ ` .objectui-sha ` is byte-identical to what it was before the run — a failed bump
94+ leaves no half-applied state. It used to: the pin file was written * before* the
95+ run read the commit subject, so ` git log ` failing killed the script under ` set -e `
96+ with the file already rewritten, no changeset, no commit, and a bare
97+ ` fatal: bad object ` as the whole explanation. Re-running did not self-correct,
98+ because the pin file now held the bad SHA.
99+
100+ You reach this with no argument at all — ` git rev-parse HEAD ` exits ** 0** and
101+ prints the sha even when that commit's object is missing from the store, since it
102+ resolves the ref without reading the object. A partial clone that has not fetched
103+ the object, or an interrupted object store, is enough. The remedy the message
104+ names is ` git -C <objectui> fetch origin ` , then re-run the bump.
105+
106+ ` pnpm check:objectui-bump ` (` scripts/bump-objectui.selftest.sh ` , run by the lint
107+ job) pins this: it asserts the file's ** bytes** across a refused run, because the
108+ broken and the fixed script both exit non-zero here and only the file tells them
109+ apart.
110+
81111#### After the pin moves: run the declaration-parity ratchet (#5960 )
82112
83113The bump has a second half, and it is not optional:
0 commit comments