4 ms·

I have completely opposite opinion on this. Writing commit messages is one of these mundane chores I’d gladly delegate to LLMs which are very very good at this

I have completely opposite opinion on this. Writing commit messages is one of these mundane chores I’d gladly delegate to LLMs which are very very good at this kind of thing. I mean, if you really know you code, you know it, there is no much value in reinforcing it in your head one more time via writing comprehensive commit messages - it’s a waste of time, imho.

deleted 11mo ago
[deleted]
lelandbatey 11mo ago
Sounds like you haven't been working long enough to forget your decisions, which you WILL do eventually. In such cases, where you're looking at code you wrote 10 years ago and you find a weird line, when you view the git blame and read the commit message, you'll be very thankful that you explain not just "what" you did, but "why" you did this, something an AI will have a very hard time doing. You don't have to if you don't want to, but if you think "this commit message is just a summary of the changes made", you'll never write a useful commit message.
- ekropotin 11mo ago
  I’ve been working in the industry for two decades, and I think commit messages is not the best place for storing decisions and associated context. I personally prefer ADRs.
  - g-b-r 11mo ago
    Two decades and you don't see any value in writing down what's currently in your head? Anyhow, ADRs are good, but they stand for Architectural decisions, not every decision is at that level. In general, if there's a better place to store explanations, do use it, but often, in many projects, commit messages are the least bad place; and it's enormously better to write there than nowhere at all.
    - bjourne 11mo ago
      Line comments work pretty well for explanation storage. :) Almost every programming language support that feature.
      - g-b-r 11mo ago
        They can sure be good, and are often indeed a better place, but unfortunately most people don't want too many lines of comments in the code. We sure should have better tools to handle code annotations, but commit messages are a not too bad fallback until we get them
- sroussey 11mo ago
  That’s why you put the comment in the code
  - lexicality 11mo ago
    comments rot as the code changes around them
torben-friis 11mo ago
Neither the code nor the AI know WHY a commit it being made. This context should at the very least be linked.
- salomonk_mur 11mo ago
  Man, 99% of non-bug-fix commits don't have a why other than "advance the current task". Almost all commits live in tandem with some large feature or change being made. The reason for absolutely all of them is the same - build the thing .
  - torben-friis 11mo ago
    >other than "advance the current task" How do you expect someone to know what “the current task” was when they’re tracking down a bug 2 years down the line?
  - crabmusket 11mo ago
    Then write that and link to the current task. That's the why. You don't need an LLM for that.
  - merelysounds 11mo ago
    Perhaps this is about commit granularity. If keeping the history about advancing the task is not useful, then I’d merge these commits together before merging the PR; in some workflows this is set up to happen automatically too.
  - eternityforest 11mo ago
    Maybe what we need is a pre-commit hook that prefixes every commit with the name of the branch it's being made onto
- bjourne 11mo ago
  For 99% of all commits the WHY is fully answered by the diff itself.
  - 11mo ago
hobofan 11mo ago
I agree in principle, but in practice, it's horrible right now. Most AI generate commit messages and PR descriptions are much too verbose and contain 0 additional informational value that couldn't be parsed from the code directly. Most of the time I'd rather read 2 sentences written by a human than a wall of text with redundant information.
michaelcampbell 11mo ago
> I mean, if you really know you code, you know it, there is no much value in reinforcing it in your head one more time via writing comprehensive commit messages - it’s a waste of time, imho. I know the code...when I write it. But 2 weeks later all the context is gone, and that's just _for me_. For my colleagues who also have to be in that code, they don't even start with context. I mean do what works for you, but understand the bulk of the work that this applies to is for >1 person shops with code bases too big to fit in ones head at all, much less for more than a day or so.

deleted 11mo ago

[deleted]

lelandbatey 11mo ago

Sounds like you haven't been working long enough to forget your decisions, which you WILL do eventually. In such cases, where you're looking at code you wrote 10 years ago and you find a weird line, when you view the git blame and read the commit message, you'll be very thankful that you explain not just "what" you did, but "why" you did this, something an AI will have a very hard time doing. You don't have to if you don't want to, but if you think "this commit message is just a summary of the changes made", you'll never write a useful commit message.

ekropotin 11mo ago
I’ve been working in the industry for two decades, and I think commit messages is not the best place for storing decisions and associated context. I personally prefer ADRs.
- g-b-r 11mo ago
  Two decades and you don't see any value in writing down what's currently in your head? Anyhow, ADRs are good, but they stand for Architectural decisions, not every decision is at that level. In general, if there's a better place to store explanations, do use it, but often, in many projects, commit messages are the least bad place; and it's enormously better to write there than nowhere at all.
  - bjourne 11mo ago
    Line comments work pretty well for explanation storage. :) Almost every programming language support that feature.
    - g-b-r 11mo ago
      They can sure be good, and are often indeed a better place, but unfortunately most people don't want too many lines of comments in the code. We sure should have better tools to handle code annotations, but commit messages are a not too bad fallback until we get them
sroussey 11mo ago
That’s why you put the comment in the code
- lexicality 11mo ago
  comments rot as the code changes around them

torben-friis 11mo ago

Neither the code nor the AI know WHY a commit it being made. This context should at the very least be linked.

salomonk_mur 11mo ago
Man, 99% of non-bug-fix commits don't have a why other than "advance the current task". Almost all commits live in tandem with some large feature or change being made. The reason for absolutely all of them is the same - build the thing .
- torben-friis 11mo ago
  >other than "advance the current task" How do you expect someone to know what “the current task” was when they’re tracking down a bug 2 years down the line?
- crabmusket 11mo ago
  Then write that and link to the current task. That's the why. You don't need an LLM for that.
- merelysounds 11mo ago
  Perhaps this is about commit granularity. If keeping the history about advancing the task is not useful, then I’d merge these commits together before merging the PR; in some workflows this is set up to happen automatically too.
- eternityforest 11mo ago
  Maybe what we need is a pre-commit hook that prefixes every commit with the name of the branch it's being made onto
bjourne 11mo ago
For 99% of all commits the WHY is fully answered by the diff itself.
- 11mo ago

hobofan 11mo ago

I agree in principle, but in practice, it's horrible right now. Most AI generate commit messages and PR descriptions are much too verbose and contain 0 additional informational value that couldn't be parsed from the code directly. Most of the time I'd rather read 2 sentences written by a human than a wall of text with redundant information.

michaelcampbell 11mo ago

> I mean, if you really know you code, you know it, there is no much value in reinforcing it in your head one more time via writing comprehensive commit messages - it’s a waste of time, imho. I know the code...when I write it. But 2 weeks later all the context is gone, and that's just _for me_. For my colleagues who also have to be in that code, they don't even start with context. I mean do what works for you, but understand the bulk of the work that this applies to is for >1 person shops with code bases too big to fit in ones head at all, much less for more than a day or so.