21 ms·

I also want to slightly disagree, or rather state a minimum: The most important part of a commit message is the context. Good enough commit log: utils: M

I also want to slightly disagree, or rather state a minimum: The most important part of a commit message is the context. Good enough commit log: utils: Minor drivers: Fix assets: Update docs: Typo Hopeless commit log: Minor Fix Update Typo Context should answer the "what". Think of it as the one word you tell a new conversation participant to let them realize what you are talking about.

mcluck 3y ago
Totally disagree on drivers: Fix Let's say your fix causes issues later. When I read the commit message, I want to understand what you were trying to fix so I don't accidentally re-introduce the problem when I fix your fix
- quickthrower2 3y ago
  For that you have external bug tracking systems. Although I tend to have a short summary and mention the ticket number. Therefore the comment stands alone but also has that extra detail outside.
  - chris_wot 3y ago
    Yeah, don’t do that. The LibreOffice code is littered with commits from bug tracking systems we no longer have access to or don’t exist any more. Explain the issue, and by all means mention the bug number, but you must explain the issue you are dealing with.
    - mcny 3y ago
      At $work, I noticed someone was regularly committing with just a dot . as a commit message. The problem was that this repo does not have automatic scss => css for whatever reason and there's a designated person who untangles the mess and fixes people's bad scss and regenerates the css files (among other duties). After about a few dozen times, they just started putting a dot as a commit message. Point is bad commit messages are sometimes a symptom to a larger problem and as with this vendor it is often a process problem, not an individual developer problem. In my opinion, the main problem here is that management simply doesn't care she it doesn't empower leads and developers who should care.
      - ZealousIdeal 3y ago
        I agree such patterns are indicative of systemic issues. In my experiences, those process issues emit their own structured behavioral patterns. In your example, the "." commit is now a convention that indicates a specific process happened. I am not certain what the costs of fixing the root problem are, though I'd anticipate they could be expensive and difficult at this point given the time commitment to restructure the repo and automate the scss=>css. Whereas the expense of an esoteric "." commit appears relatively cheap given the need of a human to untangle the mess which cannot be automated away (without a redesign).
    - quickthrower2 3y ago
      That is what I meant by: > Although I tend to have a short summary and mention the ticket number. So for example XJ-8883 - Ensure DB connections are closed sooner in main pool
- anordal 3y ago
  Do you totally disagree that this is the minimum? I'm only saying that the context is the minimum. I refuse to disagree with you about things I'm not saying.
  - mcluck 3y ago
    I'm disagreeing to both points. That's not an acceptable commit message at all. I don't need to know you were working on drivers, that's obvious from the files you were working on. The minimum for a commit message should be the why, not the what
hmeh 3y ago
There’s another way that feels totally unnatural at first, but puts the subject (the most important part) of the commit message first. It makes the commit about the change and the code, rather than the author. This is how we do it in all of our projects. I fought it at first, but I was wrong and it’s a lot better. Example: EntityStore build method records the specifier argument when given Article about it: https://github.com/aaronjensen/software-development/blob/master/commit-messages.md#subject-first-commit-messages https://github.com/aaronjensen/software-development/blob/mas...

mcluck 3y ago

Totally disagree on drivers: Fix Let's say your fix causes issues later. When I read the commit message, I want to understand what you were trying to fix so I don't accidentally re-introduce the problem when I fix your fix

quickthrower2 3y ago
For that you have external bug tracking systems. Although I tend to have a short summary and mention the ticket number. Therefore the comment stands alone but also has that extra detail outside.
- chris_wot 3y ago
  Yeah, don’t do that. The LibreOffice code is littered with commits from bug tracking systems we no longer have access to or don’t exist any more. Explain the issue, and by all means mention the bug number, but you must explain the issue you are dealing with.
  - mcny 3y ago
    At $work, I noticed someone was regularly committing with just a dot . as a commit message. The problem was that this repo does not have automatic scss => css for whatever reason and there's a designated person who untangles the mess and fixes people's bad scss and regenerates the css files (among other duties). After about a few dozen times, they just started putting a dot as a commit message. Point is bad commit messages are sometimes a symptom to a larger problem and as with this vendor it is often a process problem, not an individual developer problem. In my opinion, the main problem here is that management simply doesn't care she it doesn't empower leads and developers who should care.
    - ZealousIdeal 3y ago
      I agree such patterns are indicative of systemic issues. In my experiences, those process issues emit their own structured behavioral patterns. In your example, the "." commit is now a convention that indicates a specific process happened. I am not certain what the costs of fixing the root problem are, though I'd anticipate they could be expensive and difficult at this point given the time commitment to restructure the repo and automate the scss=>css. Whereas the expense of an esoteric "." commit appears relatively cheap given the need of a human to untangle the mess which cannot be automated away (without a redesign).
  - quickthrower2 3y ago
    That is what I meant by: > Although I tend to have a short summary and mention the ticket number. So for example XJ-8883 - Ensure DB connections are closed sooner in main pool
anordal 3y ago
Do you totally disagree that this is the minimum? I'm only saying that the context is the minimum. I refuse to disagree with you about things I'm not saying.
- mcluck 3y ago
  I'm disagreeing to both points. That's not an acceptable commit message at all. I don't need to know you were working on drivers, that's obvious from the files you were working on. The minimum for a commit message should be the why, not the what

hmeh 3y ago

There’s another way that feels totally unnatural at first, but puts the subject (the most important part) of the commit message first. It makes the commit about the change and the code, rather than the author. This is how we do it in all of our projects. I fought it at first, but I was wrong and it’s a lot better. Example: EntityStore build method records the specifier argument when given Article about it: https://github.com/aaronjensen/software-development/blob/master/commit-messages.md#subject-first-commit-messages https://github.com/aaronjensen/software-development/blob/mas...