From 6cd99ddbc33d09ca33e0d8f379c33bae9afbfae2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sun, 23 Aug 2026 18:38:41 +0000 Subject: [PATCH] convention: the two ways commit-by-path bites -m/-F goes before the --, or git reads the message as a pathspec. And it only works on tracked files, so a commit introducing a new one needs git add first. Got the second wrong cutting 2026.08.23.05: the commit failed, the tag went onto the previous commit, and the release had no plan in it. Caught only by checking what the tag pointed at afterwards, which is now the reason to always check. Co-Authored-By: Claude Opus 5 Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 --- CLAUDE.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index 6809dbb9..e13ac457 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -372,6 +372,12 @@ another session's roles work, swept up mid-`git add`. The other session was righ rewriting shared history to fix a message is the worse trade — so the record was corrected with a follow-up note instead. Cheap to avoid, awkward to undo. +Two things about the form itself, both learned the same night. `-m`/`-F` goes BEFORE the `--`, or git +reads the message as a pathspec. And it only works on **tracked** files — a new file must be `git add`ed +first, so a commit introducing one is `git add ` then `git commit -- `, naming every path. +Getting that wrong fails loudly, which is the good case: the release tag that followed it went onto the +wrong commit, and only because the tag was checked afterwards did that surface at all. + **An agent's commit names the session that made it.** A trailer, below `Co-Authored-By`: ```