That works great if you're the only person on the codebase.
In practice, one person on your team uses Claude, one uses Copilot, two use neither. Commit Changelogs makes readable changelogs a property of the repo, not of whoever happened to be in the mood to prompt an LLM that day.
Also — it reads the actual diff, not just your commit message. "fix stuff" becomes a proper entry describing what actually changed. That's the part no one bothers to do manually.
Fair enough, in our team we all got the same tools, but we're a smaller shop.
> "fix stuff" becomes a proper entry describing what actually changed.
Typically the diff tells this, what I need to know is why things changed, but almost always it's better to put that in comments I find. Assuming it's not obvious that is.
So personally I'd be more interested in something that ensured I didn't encode a lot of implicit assumptions and such without documenting it in form of comments, or at the very least the commit message.
I can see from the diff that my colleague swapped out an inner loop with one that does things slightly differently, I can see what the new code does, but why is not always obvious and should be documented.
Fair point — the "why" lives in the developer's head and no diff reader can recover it.
The bet is that automating the "what" frees up your commit message to carry the "why" instead. Most messages today are wasted describing what changed because that felt easier to type.
The pre-commit nudge you're describing is the better product though.
What has changed is pretty obvious. However without further input or context I can't tell why it changed. So I have to ask my colleague which informs me that the item_price field might be zero if it's not available, but the totals are always accurate.
Well, if he'd written that in a comment above, or at least in the commit message, I wouldn't have to disturb him and wait for him to respond. That's the sort of issues I struggle with the most by far when it comes to browsing old commit history.
Anyway, just my 2 cents, perhaps it's different for others with other types of work.
That example is spot on and I won't pretend the tool solves it — it can see the field name changed, not that item_price can be zero.
Honestly it's made me think the more useful thing is a pre-commit prompt: "this change looks non-obvious, add a comment?" rather than a post-push summary. Different problem entirely.
I literally had a similar case just now. In an integration, if a status field contained X it was changed to Y before the status processing code. My change acted on X hence failed due to status being changed to Y up front.
Once I find the offending line, I can easily see what happened, but the why is missing.
Fortunately in this case it was documented in the ticket, but would have been preferable to be in code. Without the ticket description I would have been lost.
So yeah for me and my team, a tool which tries to identify such cases and alert the dev "oy, this change might not be obvious to others and is lacking comments or commit message explanation" would be much more valuable I think.
Perhaps a more difficult task, though I've been surprised by how good these models are these days.
If I'm already using Codex or Claude to help with code, why wouldn't I just have them help me with the commit message if I feel that's needed?
In other words, in a world where LLMs are used by developers already, why would I pay extra for this?
That works great if you're the only person on the codebase.
In practice, one person on your team uses Claude, one uses Copilot, two use neither. Commit Changelogs makes readable changelogs a property of the repo, not of whoever happened to be in the mood to prompt an LLM that day.
Also — it reads the actual diff, not just your commit message. "fix stuff" becomes a proper entry describing what actually changed. That's the part no one bothers to do manually.
Fair enough, in our team we all got the same tools, but we're a smaller shop.
> "fix stuff" becomes a proper entry describing what actually changed.
Typically the diff tells this, what I need to know is why things changed, but almost always it's better to put that in comments I find. Assuming it's not obvious that is.
So personally I'd be more interested in something that ensured I didn't encode a lot of implicit assumptions and such without documenting it in form of comments, or at the very least the commit message.
I can see from the diff that my colleague swapped out an inner loop with one that does things slightly differently, I can see what the new code does, but why is not always obvious and should be documented.
Fair point — the "why" lives in the developer's head and no diff reader can recover it.
The bet is that automating the "what" frees up your commit message to carry the "why" instead. Most messages today are wasted describing what changed because that felt easier to type.
The pre-commit nudge you're describing is the better product though.
> The bet is that automating the "what" frees up your commit message to carry the "why" instead.
Right. For my work I'm not sure that bet would pay off. For (a contrived) example, say I see my colleague has changed a calculation from using
to What has changed is pretty obvious. However without further input or context I can't tell why it changed. So I have to ask my colleague which informs me that the item_price field might be zero if it's not available, but the totals are always accurate.Well, if he'd written that in a comment above, or at least in the commit message, I wouldn't have to disturb him and wait for him to respond. That's the sort of issues I struggle with the most by far when it comes to browsing old commit history.
Anyway, just my 2 cents, perhaps it's different for others with other types of work.
That example is spot on and I won't pretend the tool solves it — it can see the field name changed, not that item_price can be zero.
Honestly it's made me think the more useful thing is a pre-commit prompt: "this change looks non-obvious, add a comment?" rather than a post-push summary. Different problem entirely.
Good 2 cents.
I literally had a similar case just now. In an integration, if a status field contained X it was changed to Y before the status processing code. My change acted on X hence failed due to status being changed to Y up front.
Once I find the offending line, I can easily see what happened, but the why is missing.
Fortunately in this case it was documented in the ticket, but would have been preferable to be in code. Without the ticket description I would have been lost.
So yeah for me and my team, a tool which tries to identify such cases and alert the dev "oy, this change might not be obvious to others and is lacking comments or commit message explanation" would be much more valuable I think.
Perhaps a more difficult task, though I've been surprised by how good these models are these days.
[dead]
comment guys who have this problem
will you use this app ?