3 ms·

I think that the idea of generating a commit message based on the content (diff) of the commit is fundamentally wrong. Even before coding harnesses become main

I think that the idea of generating a commit message based on the content (diff) of the commit is fundamentally wrong. Even before coding harnesses become mainstream, a lot of tools offered to automatically generate commit messages based on the diff (I think JetBrains IDEs started to offer it very early) and I always cringed when I've seen it. The reason why I don't like diff-base commit messages is because they are redundant. If I want an LLM-generated summary of the diff, I can easily generate it myself, there is absolutely no reason to put it in the commit message. What I would like to see in the commit message is some additional context that is not a part of the diff. I don't need to read what has changed, because I can already can see it in the diff (or get an LLM to summarize it for me). But I often do need to understand why this change was made. What were they trying to achieve? That's the important part that is not contained in the diff itself. And this is the part that diff-base commits rarely contain. I think that even something simple like a link to a Jira (or other bugtracker ticket) is much more helpful than diff summary. Maybe instead of "fix" or "update" you could write just a couple of words about what are you trying to fix and why does it need updated. Still better, than a diff-summary.

miki123211 7d ago
This is why, if you have the agent generate the commit message at all, it has to be the same agent that wrote the code, in the same session. I usually have it lead with a paragraph or two of context on why the change was made (though I often use it as just a tool to turn my rambling on that question into proper English), followed by a couple paragraphs of "abstract" explaining the change (because an LLM-generated summary reviewed by the person who made the commit is better than something which the person reading can get themselves).
- adastra22 6d ago
  I don't see how that would improve the situation? If I do it with the same agent/same context, it tends to just report what it did. Which is the diff, repeated in prose.
  - miki123211 6d ago
    The agent is usually told why it was making the change (I at least tend to start my prompts with a description of the problem we're solving), so, if prompted correctly, it can lead with "there was a bug, we root-caused it and here's what the root-cause was", then explain what the fix entailed.
deleted 7d ago
[deleted]
grayxu 6d ago
true
pc86 6d ago
> But I often do need to understand why this change was made. This is the reason (and IMO the only reason) code should be commented. The why can often be hundreds of characters explaining technical limitations at the time, business considerations, or even just "we know this will break in a non-trivial number of instances but it's an incremental step forward to our end goal so we're just doing it."

miki123211 7d ago

This is why, if you have the agent generate the commit message at all, it has to be the same agent that wrote the code, in the same session. I usually have it lead with a paragraph or two of context on why the change was made (though I often use it as just a tool to turn my rambling on that question into proper English), followed by a couple paragraphs of "abstract" explaining the change (because an LLM-generated summary reviewed by the person who made the commit is better than something which the person reading can get themselves).

adastra22 6d ago
I don't see how that would improve the situation? If I do it with the same agent/same context, it tends to just report what it did. Which is the diff, repeated in prose.
- miki123211 6d ago
  The agent is usually told why it was making the change (I at least tend to start my prompts with a description of the problem we're solving), so, if prompted correctly, it can lead with "there was a bug, we root-caused it and here's what the root-cause was", then explain what the fix entailed.

deleted 7d ago

[deleted]

grayxu 6d ago

true

pc86 6d ago

> But I often do need to understand why this change was made. This is the reason (and IMO the only reason) code should be commented. The why can often be hundreds of characters explaining technical limitations at the time, business considerations, or even just "we know this will break in a non-trivial number of instances but it's an incremental step forward to our end goal so we're just doing it."