Found reviewing #86 (multi-record grammar) directly rather than reading its report.
Same message, two commands, two answers:
Feat (#1)
* change 1
Limit: only a test 1
Record-Id: r-ghtest1
* change 2
Limit: only a test 2
Record-Id: r-ghtest2
$ commitlore parse --message-file gh.txt
Limit: only a test 2
Record-Id: r-ghtest2 ← one record
$ git commit -F gh.txt && commitlore context --no-index
r-ghtest1 a0c85718 [claim] only a test 1
r-ghtest2 a0c85718 [claim] only a test 2 ← two records
parse's own help says "Parse a commit message into its CommitLore trailers (SPEC §2)". If the message carries two record blocks and parse reports one, parse is wrong about the message — and it is the command a human reaches for to ask exactly that question.
Why this matters more than it looks
#86 shipped precisely so that a squashed message's records stop disappearing. The query path was fixed. parse was not, so the diagnostic tool still shows the pre-fix answer.
Anyone debugging a squash — the situation #86 exists for — will run parse, see one record, and conclude the fix did not work or that the records were lost. The tool now disagrees with itself about its central data structure.
It is also the seventh instance of this project's recurring shape, in a new place: an answer that does not carry what it could not see. parse does not say "showing the last of 2 blocks"; it just shows one.
Also unresolved
Two blocks declaring the same Record-Id in one message: parse shows one and says nothing. The index carries an identityCollision field (visible in context --json), so the collision concept exists — it appears not to be reached on this path.
Fix
parse reports every block, with a marker for which is the message's own final block versus an inherited/earlier one. If a single-block message must keep its current output byte-for-byte — and it should — make the multi-block form additive, exactly as #86 made the grammar itself.
Found reviewing #86 (multi-record grammar) directly rather than reading its report.
Same message, two commands, two answers:
parse's own help says "Parse a commit message into its CommitLore trailers (SPEC §2)". If the message carries two record blocks andparsereports one,parseis wrong about the message — and it is the command a human reaches for to ask exactly that question.Why this matters more than it looks
#86 shipped precisely so that a squashed message's records stop disappearing. The query path was fixed.
parsewas not, so the diagnostic tool still shows the pre-fix answer.Anyone debugging a squash — the situation #86 exists for — will run
parse, see one record, and conclude the fix did not work or that the records were lost. The tool now disagrees with itself about its central data structure.It is also the seventh instance of this project's recurring shape, in a new place: an answer that does not carry what it could not see.
parsedoes not say "showing the last of 2 blocks"; it just shows one.Also unresolved
Two blocks declaring the same
Record-Idin one message:parseshows one and says nothing. The index carries anidentityCollisionfield (visible incontext --json), so the collision concept exists — it appears not to be reached on this path.Fix
parsereports every block, with a marker for which is the message's own final block versus an inherited/earlier one. If a single-block message must keep its current output byte-for-byte — and it should — make the multi-block form additive, exactly as #86 made the grammar itself.