3 ms·

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.
- torben-friis 11mo ago
  Hard disagree, though it’s probably dependent on your domain and/or how expressive your test suite is. But even if that were true, reading a two liner explanation is very obviously more time efficient than reviewing a whole commit diff. Super common case: you got a subtle bug causing unexpected values in data. You know from the db or logs that it started on 2025-03-02. You check the deployment(s)of that day and there are ~20 of them. You can quickly read 20 lines in the log and have a good guess of which is likely to be related or go for a round of re-reviewing 20 multi file pull requests and reverse engineer the context from code.
  - bjourne 11mo ago
    "Super common case" is "initial commit", "fix spelling in README.md", or "small refactor". If your "super common case" is "subtle bug causing unexpected values in data" then you are doing something very, very wrong.

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.

torben-friis 11mo ago
Hard disagree, though it’s probably dependent on your domain and/or how expressive your test suite is. But even if that were true, reading a two liner explanation is very obviously more time efficient than reviewing a whole commit diff. Super common case: you got a subtle bug causing unexpected values in data. You know from the db or logs that it started on 2025-03-02. You check the deployment(s)of that day and there are ~20 of them. You can quickly read 20 lines in the log and have a good guess of which is likely to be related or go for a round of re-reviewing 20 multi file pull requests and reverse engineer the context from code.
- bjourne 11mo ago
  "Super common case" is "initial commit", "fix spelling in README.md", or "small refactor". If your "super common case" is "subtle bug causing unexpected values in data" then you are doing something very, very wrong.