AI summary:
Here's what happens with git commit --amend:
Notes will be combined — but they'll be attached to the amended commit's new hash, and the old commit's notes will be orphaned.
Here's the flow, walking through the code in src/index.ts:
The amend is detected — The regex on line 14 (/\bgit\s+commit\b/) matches git commit --amend, so the tool.execute.after hook fires (line 140).
New HEAD is resolved — On line 154, it runs git rev-parse HEAD, which returns the new hash created by the amend (amending always creates a new commit object).
Existing note check — Lines 188–195 try to read an existing note on that new hash. Since it's a brand-new hash, there won't be an existing note, so existingNote will be empty.
Transcript is attached — The new transcript gets attached to the new commit hash (line 201).
The important consequence: The old (pre-amend) commit's note still exists under its original hash in refs/notes/opencode, but that commit is no longer reachable from any branch. The note becomes orphaned — it won't show up in scanCommitsWithNotes (which walks the branch history) and won't be garbage-collected until git gc runs.
Summary
Notes are not combined in the way you'd want — the amend creates a new hash, and the plugin treats it as a fresh commit.
The old note becomes orphaned (unreachable but not deleted).
The new note only captures messages since the last prevCommitTimestamp update, not the full history.
Would you like me to plan a fix for this? For example, the plugin could detect --amend in the command, read the note from the pre-amend HEAD (captured in tool.execute.before), and prepend it to the new note.
AI summary:
Here's what happens with git commit --amend:
Notes will be combined — but they'll be attached to the amended commit's new hash, and the old commit's notes will be orphaned.
Here's the flow, walking through the code in src/index.ts:
The amend is detected — The regex on line 14 (/\bgit\s+commit\b/) matches git commit --amend, so the tool.execute.after hook fires (line 140).
New HEAD is resolved — On line 154, it runs git rev-parse HEAD, which returns the new hash created by the amend (amending always creates a new commit object).
Existing note check — Lines 188–195 try to read an existing note on that new hash. Since it's a brand-new hash, there won't be an existing note, so existingNote will be empty.
Transcript is attached — The new transcript gets attached to the new commit hash (line 201).
The important consequence: The old (pre-amend) commit's note still exists under its original hash in refs/notes/opencode, but that commit is no longer reachable from any branch. The note becomes orphaned — it won't show up in scanCommitsWithNotes (which walks the branch history) and won't be garbage-collected until git gc runs.
Summary
Notes are not combined in the way you'd want — the amend creates a new hash, and the plugin treats it as a fresh commit.
The old note becomes orphaned (unreachable but not deleted).
The new note only captures messages since the last prevCommitTimestamp update, not the full history.
Would you like me to plan a fix for this? For example, the plugin could detect --amend in the command, read the note from the pre-amend HEAD (captured in tool.execute.before), and prepend it to the new note.