TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with frontmatter carrying id, status, created date and order, and the prose body copied across verbatim. TODO.md becomes a generated index (bun run todo:index). Dates: where an item's prose stated one it is used; otherwise its old section's; otherwise 2026-08-20, floored at the day before the split rather than invented. date_source records which. Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is the identity, frontmatter is the machine's half and the body is the owner's. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
---
|
|
id: fleet/a-way-to-mark-a-commit-this-one-ships-so-a
|
|
title: "A way to mark a commit \"this one ships\", so a release is not just `master`'s tip"
|
|
theme: fleet
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 2
|
|
---
|
|
|
|
**A way to mark a commit "this one ships", so a release is not just `master`'s tip.** Wanted
|
|
2026-08-21. **No version numbers** — not now — and **not a tag**: the owner does not want a second
|
|
ref to mint and push for something the commit itself could carry. So a **codeword in the commit
|
|
message**, and the fleet updater pulls to the newest commit carrying it rather than to whatever
|
|
`master` points at.
|
|
|
|
That distinction is the whole value: today a server updates to the tip, so an in-progress commit
|
|
ships the moment it is pushed. A marker makes shipping a deliberate act while leaving the push
|
|
unchanged.
|
|
|
|
Shape to settle when it is built:
|
|
|
|
- **A trailer, not a word in prose** — `Release: yes` on its own line, in the same family as
|
|
`Co-Authored-By`. `git log --grep='^Release:' --format=%H -1` then gives the target SHA in one
|
|
command, and no commit message that merely *talks* about a release matches by accident.
|
|
- **The trade against a tag, stated honestly:** a tag can be moved or deleted when a release turns
|
|
out to be bad; a commit message cannot be edited once pushed. Un-marking means marking a newer
|
|
commit — which is a forward-only, revert-shaped workflow. That is a fine answer, but it should
|
|
be a chosen one.
|
|
- The updater then does a checkout at that SHA, not a `pull` — same discipline the plugin-pinning
|
|
item asks for: **verify `rev-parse HEAD` matches, or refuse.**
|