Would you use a GitHub App that auto-generates changelogs from commit diffs?
I'm building CommitLog — a GitHub App that reads your commit diff on every push
and posts a human-readable changelog as a comment, powered by Claude AI.
12 comments
The commit-level approach is a good start, but the real gap isn't generating the changelog, it's distributing it.
Your users don't read your GitHub Releases page. They need it in an email digest, a social post, an in-app announcement. I'm building something in this space (Recaip) and the biggest insight was: one AI-generated output isn't enough, you need multiple formats for multiple audiences from a single PR merge. Happy to share what I've learned about the multi-audience problem if anyone's interested.
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?
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.
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.
> "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. 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
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.
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
price_selected_items = num_selected_items * invoice.item_price
price_selected_items = num_selected_items * invoice.total_item_price / invoice.total_items
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.
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.
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.
comment guys who have this problem
will you use this app ?