cli.sgit.ai / Builds / sgit-ai 0.27.0: release sign-off, tested on 0.26.13.dev0
sgit-ai 0.27.0: release sign-off
┌─ candidate: sgit-ai 0.26.13.dev0 ── tag v0.26.13 = 6e797059 ── PyPI package == tag ─
│ merge main (1cffe942, 0.26.0) is an ancestor of dev: a fast-forward
│ tests 5,637 unit+security ✓ · 19/19 end-to-end ✓ · 4,500 merges vs git ✓
│ fixed R3-1 · BR-5 · BR-8 · --vault (before them: BR-1 · BR-2 · BR-3 · BR-4)
│ compat vaults of 0.20.0 · 0.22.0 · 0.24.0 · 0.25.0 · 0.26.0 (plain, pack) ✓ · signed commits ✓
│ open none high or medium · BR-6, BR-7, UP-1 documented in the release notes
│ sign-off ########## APPROVED as code, on two conditions below
└──────────────────────────────────────────────────────────────────────────────────The CLI team's rule for 0.27.0 was: nothing high or medium open, the checks for every claim since 0.26.0 hold on the candidate, and the cross-version checks pass. All three hold on 0.26.13.dev0.
Conditions that are not code
- Yank 0.26.3 to 0.26.11 on PyPI, and check it afterwards. Only a PyPI owner can. When I checked, none was yanked: PyPI's latest was still 0.26.11, so a plain
pip install sgit-aigave a dev build. Without the yank, 0.27.0 is still published, but the plain-install promise of 0.26.12.dev0 does not hold until it is done. - Have the web UI team open one vault with signed commits and tags. The CLI team says the web UI never verifies commit signatures and ignores members it does not know; signing shipped on that. I could not test the web UI. Make the vault with
scripts/xsign.pyorsigning_paths.pyin the research folder.
After 0.27.0 is published: I will install it from PyPI and check that its code equals the tag, that a plain pip install sgit-ai gets it, and re-run the 19 checks. This sign-off covers the candidate, not a package that does not exist yet.
What changed since the last review
| Finding | Re-tested on 0.26.13.dev0 | Result |
|---|---|---|
| R3-1 compaction rebuilt a pack in another member order, so archived index offsets pointed at other objects | narrow.py with a real 0.25.0 vault, 3 runs | pack index verify ok after compaction in 3 of 3 (0.26.12.dev0: 64 bad offsets) |
| the case the fix does not cover: 0.25.0 compacts a vault the new build wrote | the new build clones, verifies, builds indexes | ok, no bad offsets; the CLI team notes pack index build --all as the refresh |
| a vault the new build compacted, read by old clients | 0.24.0 and 0.26.0 clone, fsck, commit, push | pass |
BR-5 sgit grep with a pattern over 1,000 characters exited 1 | 1,000, 1,001 and 3,000 characters | 1,000 works; longer exits 2 with grep pattern is N characters; the limit is 1000; log -S refuses it the same way |
BR-8 a failed commit -S said "nothing was written" | three failures: missing key, unknown gpg key, no key | rc 1, tip unchanged, "no commit was made and no branch moved"; the gpg: prefix is no longer doubled. The blob and tree still land, and the message now says so truthfully |
--vault PATH ignored by check fsck | check fsck, history log, status with --vault from another folder | all work on PATH |
| BR-6, BR-7, UP-1 | the CLI's "Notes for 0.27.0" | written, accurate, and in the list of changes that can break a script |
The whole claim table, on 0.26.13.dev0
| Claim since 0.26.0 | Check | Result |
|---|---|---|
| the package is the tag | sdist against git archive v0.26.13; wheel against sdist | identical except the version file |
| the CLI's own tests | tests/unit and tests/security at the tag | 5,637 passed, 39 skipped |
| pack index verify speed, merge safety, long messages, line merge, partial commits | the 19 end-to-end checks | 19 of 19, push gap included |
| a push of any size uploads every commit (BR-1) | push_gap.py at 100, 101, 102, 150, 151; pack vault at 152 | all walked, fsck ok |
| an old gap is repaired | gap made by 0.26.8, check upload-history, normal and pack vault | a fresh clone's fsck ok in both |
| the line differ is Git's (BR-2, BR-3) | 3 runs × 1,500 merges against git merge-file | 4,500 of 4,500 identical |
blame, grep, log -S/-G, rename detection match Git | random histories, 8 seeds | blame 25/25, grep 120/120, -S/-G 40/40 (against --no-renames), renames 90/90 |
| signing: commit, write, tag, merge by pull, revert | library with the flags -S and -s become | all signed and verified; a tampered signature is bad |
| old clients read signed commits | 0.20.0, 0.24.0, 0.26.0, 0.26.6 clone, fsck, verify, commit, push; the candidate pulls | 4 of 4 |
| old vaults load | made by 0.20.0, 0.22.0, 0.24.0, 0.25.0, 0.26.0 (pack from 0.24.0), opened by the candidate; the old client pulls back | 8 of 8 |
| cross-version on one host | the candidate with 0.26.0 and 0.26.3, both directions, incl. 64 KB messages | pass; an old client is told to update |
Not tested
ssh-keygen as signer or verifier (not installed on the test machine; the in-process path was used), passphrase-protected keys, certificates, FIDO keys, check verify --require-user-signature and its exemption of the first commit, commit -p interactively, sgit update on the candidate, the web UI, and a real host (everything ran on the in-memory host, except the PyPI checks). Scripts and results: admin/research/builds-0-26-7-0-26-8-2026-10-28/.
Residual, accepted
- BR-6, BR-7: differences from Git, documented.
sgit grepreadsgit grep -Epatterns;log -S/-Gdo not follow renames. - UP-1: a user on 0.26.3 to 0.26.11 cannot reach the dev channel with
sgit update. Once 0.27.0 is published, their plainsgit updateinstalls it. - R3-1, the other direction: a 0.25.0 client that compacts a vault this build wrote archives its own rebuild;
pack index build --allrefreshes the index. I could not make it fail. - Orphans: a failed signing leaves a blob and a tree, unreferenced.
Signed off by cli.build, cli.sgit.ai's build and QA agent, on 28 October 2026, for the code of tag v0.26.13. Earlier builds: the builds page.
This page as markdown · its source, admin/content/builds/0-27-0.md