4 ms·

> my first knee-jerk reaction wouldn't be "this is for pretending to be human"... "Write commit messages as a human developer would — describe only what the co

> my first knee-jerk reaction wouldn't be "this is for pretending to be human"... "Write commit messages as a human developer would — describe only what the code change does."

peacebeard 6mo ago
~That line isn't in the file I linked, care to share the context? Seems pretty innocuous on its own.~ [edit] Never mind, find in page fail on my end.
- stordoff 6mo ago
  It's in line 56-57.
  - peacebeard 6mo ago
    Thanks! I must have had a typo when I searched the page.
deleted 6mo ago
[deleted]
amarant 6mo ago
That seems desirable? Like that's what commit messages are for. Describing the change. Much rather that than the m$ way of putting ads in commit messages
- fweimer 6mo ago
  The commit message should complement the code. Ideally, what the code does should not need a separate description, but of course there can be exceptions. Usually, it's more interesting to capture in the commit message what is not in the code: the reason why this approach was chosen and not some other obvious one. Or describe what is missing, and why it isn't needed.
  - ImPostingOnHN 6mo ago
    That sounds like design discussions best had in the issue/ticket itself, before you even start writing code. Then the commit message references the ticket and has a brief summary of the changes. Writing and reading paragraphs of design discussion in a commit message is not something that seems common.
    - skydhash 6mo ago
      Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph.
      - ImPostingOnHN 6mo ago
        > technical reasons why this solution came to be What you're describing here is a design. The most important parts of a design are the decisions and their reasoning. e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message. You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
        shakna 6mo ago
        So you'd disagree with style that Linux uses for their commits? Random example: Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region. From 99d2592023e5d0a31f5f5a83c694df48239a1e6c
- evenhash 6mo ago
  Unfortunately GitHub Copilot’s commit message generation feature is very human. It’s picked up some awful habits from lazy human devs. I almost always get some pointless “… to improve clarity” or “… for enhanced usability” at the end of the message. VS Code has a setting that promises to change the prompt it uses to generate commit messages, but it mostly ignores my instructions, even very literal ones like “don’t use the words ‘enhance’ or ‘improve’”. And oddly having it set can sometimes result in Cyrillic characters showing up at the end of the message. Ultimately I stopped using it, because editing the messages cost me more time than it saved. /rant
  - Pxtl 6mo ago
    Honestly the aggressive verbosity of github copilot is half the reason don't use its suggested comments. AI generated code comments follow an inverted-wadsworth-constant: Only the first 30% is useful.
giancarlostoro 6mo ago
As opposed to outputting debugging information, which I wouldnt be surprised if LLMs do output "debug" output blurbs which could include model specific information.
LeifCarrotson 6mo ago
The human developer would just write what the code does, because the commit also contains an email address that identifies who wrote the commit. There's no reason to write: > Commit f9205ab3 by dkenyser on 2026-3-31 at 16:05: > Fixed the foobar bug by adding a baz flag - dkenyser Because it already identified you in the commit description. The reason to add a signature to the message is that someone (or something) that isn't you is using your account, which seems like a bad idea.
- jakeinspace 6mo ago
  Aside from merges that combine commits from many authors onto a production branch or release tag. I would personally not leave an agent to do that sort of work.
  - catlifeonmars 6mo ago
    I usually avoid merge commits in favor of rebases precisely for the reason you describe above.

> my first knee-jerk reaction wouldn't be "this is for pretending to be human"... "Write commit messages as a human developer would — describe only what the code change does."

peacebeard 6mo ago

~That line isn't in the file I linked, care to share the context? Seems pretty innocuous on its own.~ [edit] Never mind, find in page fail on my end.

stordoff 6mo ago
It's in line 56-57.
- peacebeard 6mo ago
  Thanks! I must have had a typo when I searched the page.

deleted 6mo ago

[deleted]

amarant 6mo ago

That seems desirable? Like that's what commit messages are for. Describing the change. Much rather that than the m$ way of putting ads in commit messages

fweimer 6mo ago
The commit message should complement the code. Ideally, what the code does should not need a separate description, but of course there can be exceptions. Usually, it's more interesting to capture in the commit message what is not in the code: the reason why this approach was chosen and not some other obvious one. Or describe what is missing, and why it isn't needed.
- ImPostingOnHN 6mo ago
  That sounds like design discussions best had in the issue/ticket itself, before you even start writing code. Then the commit message references the ticket and has a brief summary of the changes. Writing and reading paragraphs of design discussion in a commit message is not something that seems common.
  - skydhash 6mo ago
    Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph.
    - ImPostingOnHN 6mo ago
      > technical reasons why this solution came to be What you're describing here is a design. The most important parts of a design are the decisions and their reasoning. e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message. You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
      - shakna 6mo ago
        So you'd disagree with style that Linux uses for their commits? Random example: Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region. From 99d2592023e5d0a31f5f5a83c694df48239a1e6c
evenhash 6mo ago
Unfortunately GitHub Copilot’s commit message generation feature is very human. It’s picked up some awful habits from lazy human devs. I almost always get some pointless “… to improve clarity” or “… for enhanced usability” at the end of the message. VS Code has a setting that promises to change the prompt it uses to generate commit messages, but it mostly ignores my instructions, even very literal ones like “don’t use the words ‘enhance’ or ‘improve’”. And oddly having it set can sometimes result in Cyrillic characters showing up at the end of the message. Ultimately I stopped using it, because editing the messages cost me more time than it saved. /rant
- Pxtl 6mo ago
  Honestly the aggressive verbosity of github copilot is half the reason don't use its suggested comments. AI generated code comments follow an inverted-wadsworth-constant: Only the first 30% is useful.

giancarlostoro 6mo ago

As opposed to outputting debugging information, which I wouldnt be surprised if LLMs do output "debug" output blurbs which could include model specific information.

LeifCarrotson 6mo ago

The human developer would just write what the code does, because the commit also contains an email address that identifies who wrote the commit. There's no reason to write: > Commit f9205ab3 by dkenyser on 2026-3-31 at 16:05: > Fixed the foobar bug by adding a baz flag - dkenyser Because it already identified you in the commit description. The reason to add a signature to the message is that someone (or something) that isn't you is using your account, which seems like a bad idea.

jakeinspace 6mo ago
Aside from merges that combine commits from many authors onto a production branch or release tag. I would personally not leave an agent to do that sort of work.
- catlifeonmars 6mo ago
  I usually avoid merge commits in favor of rebases precisely for the reason you describe above.