4 ms·

Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I usually write "Added ability to do foo with bar when baz is true." Commit messages

Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I usually write "Added ability to do foo with bar when baz is true." Commit messages aren't mutually exclusive to the inline documentation. I am making the case that inline documentation is far more important than commit messages.

jkaplowitz 6y ago
There's no general rule about what length a commit message should be, except that often people try to keep the first paragraph as a single short line for better readability in systems like GitHub and the git CLI. When additional detail is helpful about the motivation for or gotchas related to a commit, starting a new paragraph and elaborating there is totally fine. But I agree with you, they aren't mutually exclusive to inline documentation. The inline documentation is more important when the explanation is relevant to understanding the code which results from the commit, whereas a clear commit message is more important when the information is to illuminate the reasons for (or history surrounding) the change itself.
- systemvoltage 6y ago
  Agree with all you've said. Commit messages do serve a slightly different purpose of historical context.
- cwsx 6y ago
  I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?
  - MaxBarraclough 6y ago
    There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary https://www.conventionalcommits.org/en/v1.0.0/#summary
    - jkaplowitz 6y ago
      Ah! That seems slightly different from the format the person you're replying to described, but I have seen this version in use at one job. There was only used by one person who gave no context on why he used that format, so it's probably no coincidence in such an example that to me the extra structure seemed to add only opacity and no real value. I can absolutely imagine that being different in a company that used this convention widely and built tooling around it. Doubly so when a lot of the staff is junior enough that it's helpful guidance for structuring thoughts around what the commit does.
  - jkaplowitz 6y ago
    I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like compatibility with parsing by dev workflow dashboards or other automatic tooling. Though, I'm not sure it's a helpful restriction for commits that clarify, refactor, or clean up code. One can certainly reference an issue tracker number as the {feature/bug} element that gives the necessary context, but the strictness spreads the information around more widely than is natural. If someone was adopting that convention as a workaround for helping team members learn how to communicate, they're probably going to find that it's a very incomplete workaround.
    - cwsx 6y ago
      I should note this is normally done on a feature branch (with the ticket number attached). i.e. feature/{ticket-#}-{ticket-title} When merging you can pretty easily see what ticket each commit was for. Seems superfluous to put the same information in every commit messages.
      - jkaplowitz 6y ago
        Thanks for the clarity. Yeah, I agree it would be unhelpfully repetitive if every commit in a given feature branch merge has nearly basically the same title. That's not best practice anywhere I've worked. By contrast, referencing the ticket number (but not necessarily ticket title) is common practice in the PR message, and seems much more helpful.
xorcist 6y ago
"Supposed" to? Git was made with the intention that commit messages look like whole emails, describing not only why the change was made but also the thought process behind it, why this particular solution was chosen instead of some other etc. What you describe is a decent header, although most people would probably prefer "Add ability to" (not "Added ability to", this is a custom that goes way back before git). Inline documentation, or comments, is something else entirely. That is a moving target that can describe intended usage, remote APIs, and hard to understand passages. Commit messages describes a particular changeset, at a fixed point in time. Google it, and see that most people's ideas of a good commit message goes way beyond the header ("shortlog") line.
- alexchantavy 6y ago
  GitHub discourages making commit messages longer than a certain number of characters; it’s interesting for me to see other opinions on that.
  - andersonvom 6y ago
    You're talking about the title of the commit message. Yes, the title is supposed to be under 50 characters. Now add a blank line after it and you can write all you want (line wrap at 72 chars). If you use markdown Syntax in your commit body, github and other tools will gladly render it correctly. You can grep for commit messages with "git log --grep <pattern>" and it will also search commit bodies as well. It's beautiful!
  - smichel17 6y ago
    Adding on to sibling comment, on GitHub the additional lines they're talking about go in the box before the commit title.
- alphachloride 6y ago
  Could be selection bias. People who comment about good commit messages are most likely people who pay attention to commit messages. That does not necessarily mean they make up a majority of committers.
mcv 6y ago
Commit messages and code comments serve different purposes. The commit message should be about what you changed, so they help you find the interesting commit from a list of commit messages, whereas comments in the code should be about why the code is the way it is. Is it because of a bug in a library? Is it arbitrary? A quick fix that still has some debt? Did someone waste a lot of time on this? Commit messages are about the change, whereas comments are about the state of the code.

jkaplowitz 6y ago

There's no general rule about what length a commit message should be, except that often people try to keep the first paragraph as a single short line for better readability in systems like GitHub and the git CLI. When additional detail is helpful about the motivation for or gotchas related to a commit, starting a new paragraph and elaborating there is totally fine. But I agree with you, they aren't mutually exclusive to inline documentation. The inline documentation is more important when the explanation is relevant to understanding the code which results from the commit, whereas a clear commit message is more important when the information is to illuminate the reasons for (or history surrounding) the change itself.

systemvoltage 6y ago
Agree with all you've said. Commit messages do serve a slightly different purpose of historical context.
cwsx 6y ago
I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?
- MaxBarraclough 6y ago
  There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary https://www.conventionalcommits.org/en/v1.0.0/#summary
  - jkaplowitz 6y ago
    Ah! That seems slightly different from the format the person you're replying to described, but I have seen this version in use at one job. There was only used by one person who gave no context on why he used that format, so it's probably no coincidence in such an example that to me the extra structure seemed to add only opacity and no real value. I can absolutely imagine that being different in a company that used this convention widely and built tooling around it. Doubly so when a lot of the staff is junior enough that it's helpful guidance for structuring thoughts around what the commit does.
- jkaplowitz 6y ago
  I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like compatibility with parsing by dev workflow dashboards or other automatic tooling. Though, I'm not sure it's a helpful restriction for commits that clarify, refactor, or clean up code. One can certainly reference an issue tracker number as the {feature/bug} element that gives the necessary context, but the strictness spreads the information around more widely than is natural. If someone was adopting that convention as a workaround for helping team members learn how to communicate, they're probably going to find that it's a very incomplete workaround.
  - cwsx 6y ago
    I should note this is normally done on a feature branch (with the ticket number attached). i.e. feature/{ticket-#}-{ticket-title} When merging you can pretty easily see what ticket each commit was for. Seems superfluous to put the same information in every commit messages.
    - jkaplowitz 6y ago
      Thanks for the clarity. Yeah, I agree it would be unhelpfully repetitive if every commit in a given feature branch merge has nearly basically the same title. That's not best practice anywhere I've worked. By contrast, referencing the ticket number (but not necessarily ticket title) is common practice in the PR message, and seems much more helpful.

xorcist 6y ago

"Supposed" to? Git was made with the intention that commit messages look like whole emails, describing not only why the change was made but also the thought process behind it, why this particular solution was chosen instead of some other etc. What you describe is a decent header, although most people would probably prefer "Add ability to" (not "Added ability to", this is a custom that goes way back before git). Inline documentation, or comments, is something else entirely. That is a moving target that can describe intended usage, remote APIs, and hard to understand passages. Commit messages describes a particular changeset, at a fixed point in time. Google it, and see that most people's ideas of a good commit message goes way beyond the header ("shortlog") line.

alexchantavy 6y ago
GitHub discourages making commit messages longer than a certain number of characters; it’s interesting for me to see other opinions on that.
- andersonvom 6y ago
  You're talking about the title of the commit message. Yes, the title is supposed to be under 50 characters. Now add a blank line after it and you can write all you want (line wrap at 72 chars). If you use markdown Syntax in your commit body, github and other tools will gladly render it correctly. You can grep for commit messages with "git log --grep <pattern>" and it will also search commit bodies as well. It's beautiful!
- smichel17 6y ago
  Adding on to sibling comment, on GitHub the additional lines they're talking about go in the box before the commit title.
alphachloride 6y ago
Could be selection bias. People who comment about good commit messages are most likely people who pay attention to commit messages. That does not necessarily mean they make up a majority of committers.

mcv 6y ago

Commit messages and code comments serve different purposes. The commit message should be about what you changed, so they help you find the interesting commit from a list of commit messages, whereas comments in the code should be about why the code is the way it is. Is it because of a bug in a library? Is it arbitrary? A quick fix that still has some debt? Did someone waste a lot of time on this? Commit messages are about the change, whereas comments are about the state of the code.