7 ms·

> Second, not every change needs a great commit message. If a change is really minor, I would say minor is an okay commit message! I want to slightly disagree

by mfrw 3y ago

> Second, not every change needs a great commit message. If a change is really minor, I would say minor is an okay commit message! I want to slightly disagree on this for folks who are early on in career e.g me; I think there is a lot of value in learning to communicate precisely and having a habit of writing good commit message has certainly improved my skills, both verbal and written. Even though, this activity appears futile for a minor change; it might help to improve other skills :)

karlshea 3y ago
You’re totally right, if it’s that minor then you can type in a word or two to describe it like “spacing”.
- Izkata 3y ago
  Even something that simple falls into what vs why: You can tell it was spacing from the diff, so the commit message should be "linting" or "alignment" or something similarly more meaningful.
  - quickthrower2 3y ago
    The diff may not be visible. The person might be doing a complicated cherry pick or merge and scrolling through hundreds of commits. If the message explains it, it saves them digging in. My analogy is your bookshelf books still need jackets!
  - Vinnl 3y ago
    First line is for what, the rest of the commit message is for the why - if needed. As for "spacing", you can probably tell the why from the diff as well. The "what", however, tells you whether it's even worth opening the diff.
anordal 3y ago
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).
mytailorisrich 3y ago
Usually, in more structured professional environments every commit must link back to a change request, which them provides context. But yes, even minor changes should have a descriptive commit message that summarises the change in order to make commit history useful. Now, when the code itself needs an explanation then that should be in the form of a comment next to the code itself.
32bitkid 3y ago
I’d take it one step further: if `git log`—a hierarchical view of the connection of commits—is the only way you (and your team) interact with commit messages, then yea it’s probably fine. But, I think the value of commit messages become really apparent once you (or your team) are relying on other visualizations of commit messages like `blame` and `bisect` Tracking down the introduction of a bug with bisect and resolving to a commit whose message in “minor”, because the person in the past didn’t think this change was important enough to describe intent can quite the temporal foot-gun.
forgotmypw17 3y ago
I would strongly disagree with it, because it misses the opportunity for using the commit message as a sanity check. Accidents happen, sometimes I select the wrong file for the commit, or include changes I didn't intend. Even for the most minor commits, including "improve comment formatting ; utils.pl" allows skimming that message and comparing it to the actual commit. It also helps me be aware of what I'm doing, pointing and calling style. https://en.wikipedia.org/wiki/Pointing_and_calling https://en.wikipedia.org/wiki/Pointing_and_calling
- Cthulhu_ 3y ago
  To nitpick, the git commit already contains information about which files are affected; adding it explicitly to the commit message does not add value and, like comments, may be incorrect. I like the angular style guide's concept of "scope", like, what category or module of the application does it apply to. That said, an "utils" file is often a smell in code organization.
  - forgotmypw17 3y ago
    > the git commit already contains information about which files are affected Right, but this is not always the same as the files which I intended to be affected, and the matching of the two is the sanity check here. utils was just an example filename.
  - joshka 3y ago
    > the git commit already contains information about which files are affected; Contra: while this is true, it's worth considering how 'information about which files are effected' scales when examining the history of a repo. A commit message that simplifies and clarifies the intent is more useful than one that requires a future reader to read each git commit in full to understand the effect.

by mfrw 3y ago

karlshea 3y ago

You’re totally right, if it’s that minor then you can type in a word or two to describe it like “spacing”.

Izkata 3y ago
Even something that simple falls into what vs why: You can tell it was spacing from the diff, so the commit message should be "linting" or "alignment" or something similarly more meaningful.
- quickthrower2 3y ago
  The diff may not be visible. The person might be doing a complicated cherry pick or merge and scrolling through hundreds of commits. If the message explains it, it saves them digging in. My analogy is your bookshelf books still need jackets!
- Vinnl 3y ago
  First line is for what, the rest of the commit message is for the why - if needed. As for "spacing", you can probably tell the why from the diff as well. The "what", however, tells you whether it's even worth opening the diff.

anordal 3y ago

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).

mytailorisrich 3y ago

Usually, in more structured professional environments every commit must link back to a change request, which them provides context. But yes, even minor changes should have a descriptive commit message that summarises the change in order to make commit history useful. Now, when the code itself needs an explanation then that should be in the form of a comment next to the code itself.

32bitkid 3y ago

I’d take it one step further: if `git log`—a hierarchical view of the connection of commits—is the only way you (and your team) interact with commit messages, then yea it’s probably fine. But, I think the value of commit messages become really apparent once you (or your team) are relying on other visualizations of commit messages like `blame` and `bisect` Tracking down the introduction of a bug with bisect and resolving to a commit whose message in “minor”, because the person in the past didn’t think this change was important enough to describe intent can quite the temporal foot-gun.

forgotmypw17 3y ago

I would strongly disagree with it, because it misses the opportunity for using the commit message as a sanity check. Accidents happen, sometimes I select the wrong file for the commit, or include changes I didn't intend. Even for the most minor commits, including "improve comment formatting ; utils.pl" allows skimming that message and comparing it to the actual commit. It also helps me be aware of what I'm doing, pointing and calling style. https://en.wikipedia.org/wiki/Pointing_and_calling https://en.wikipedia.org/wiki/Pointing_and_calling

Cthulhu_ 3y ago
To nitpick, the git commit already contains information about which files are affected; adding it explicitly to the commit message does not add value and, like comments, may be incorrect. I like the angular style guide's concept of "scope", like, what category or module of the application does it apply to. That said, an "utils" file is often a smell in code organization.
- forgotmypw17 3y ago
  > the git commit already contains information about which files are affected Right, but this is not always the same as the files which I intended to be affected, and the matching of the two is the sanity check here. utils was just an example filename.
- joshka 3y ago
  > the git commit already contains information about which files are affected; Contra: while this is true, it's worth considering how 'information about which files are effected' scales when examining the history of a repo. A commit message that simplifies and clarifies the intent is more useful than one that requires a future reader to read each git commit in full to understand the effect.