upvote
Trailers were not suitable for the use case.

The scope in parentheses is doing real work. `rejected(oauth-library)` lets you do `git log --grep="rejected(auth"` to find every rejected auth decision across history.

If you flatten it to a trailer token you either lose the scope or encode it awkwardly as `Rejected-auth-oauth-library: value`, which doesn't grep cleanly and doesn't parse naturally.

reply
> The scope in parentheses is doing real work. `rejected(oauth-library)` lets you do `git log --grep="rejected(auth"` to find every rejected auth decision across history.

I'm 99% sure that grep won't find your commit because you rejected "oauth-library" and grepping for "auth" rejection. Given that LLM will make up category name, it will just get worse unless there is deterministic enforcement.

All of this really feels like people that never wrote code starting doing it via agents and started reinventing already solved issues.

reply
The “deterministic enforcement” is exactly what this enables but its not the responsibility of the spec to say that. Its harnesses or IDEs or you own implementation that will enforce that.
reply
Then why the last thing blog post says is: "No new tools. No infrastructure. Just better commits."
reply
The format is optimised for agent querying and human readability in `git log`, not for `git interpret-trailers` compatibility. Those are different use cases.
reply
git int-trailers compatibility is a nonsense phrase. You don’t care about compatibility with a helper tool. You care about the tools that use them... and git log uses them.

> The format is optimised for agent querying and human readability

Yours is key value pairs. Trailers are key value pairs. The git log can be read by humans and agents... what’s even the differentiator here?

Agents read English. But every little minutia of programming now needs something “for agents and humans”? Which is like colon-separated key value pairs... except they also have a scope in parens. Which makes all the difference to agents? tuts

reply

     Rejected: (auth-library) ...

?
reply
I think those are better suited to an issue tracker. As for changes that affected the source code, you can grep the patch in the git log too.
reply
Issue trackers are full of intent and decisions, that's true, but that's not the point here... It's about a storage that agents can use natively without the need of callings external APIs or MCPs.

And there is a slight difference between what you capture in issue trackers and what happens in reality in coding sessions.

reply