6 ms·

> feat: a commit of the type feat introduces a new feature to the codebase instead of 'feat:', why not 'feature:'? I dislike partial abbreviation because it i

> feat: a commit of the type feat introduces a new feature to the codebase instead of 'feat:', why not 'feature:'? I dislike partial abbreviation because it is confusing; yes doc for document and max for maximum make sense but in this case feat is literally a different word?

ChristianBundy 7y ago
And while we're at it, why don't we just use full sentences? Before: > feat: allow provided config object to extend other configs After > Add option for config object to extend other configs I know this isn't the point of changelogs, but I've been using the verbs from KeepAChangelog to start my commit messages and it's been going well so far. > Add template preview to status page > Change textarea to increase height on `:focus` > Remove deprecated CLI flags > Fix margin styles causing layout problems
- YorickPeterse 7y ago
  I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messages. Setting that aside, the conventional commit "standard" (https://xkcd.com/927/ https://xkcd.com/927/) doesn't focus on what I think is the most important aspect of a commit: a good commit subject and message. In fact, prefixing the subject line with certain tags limits the amount of characters you have for writing the message; assuming you want to stick with the usual 50 character limit.
  - JMTQp8lwXL 7y ago
    > feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: <-- patch feat: <-- minor breaking: <-- major
    - munk-a 7y ago
      That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.
      - JMTQp8lwXL 7y ago
        I was explaining how standard-version [0] works. Conventional Commits homepage doesn't mention anything about the '!' syntax. [1] I'm unsure if you're suggesting that's how you think it should work, or how it actually works. I haven't ever tried using the '!' syntax, so I can't say for certain. In terms of release management, it makes configuring CI jobs simpler with one less parameter. If you automatically release merges to master, you can use standard-version with conventional commit syntax. On other projects, I've seen people use GitHub PR labels to mark 'major', 'minor', or 'patch' releases (the CI system reads this information when generating releases). If you feel it's inappropriate for this information to live in your commit history, you'll need to specify it through one of these other options. Since I don't have a dedicated team for this sort of infrastructure (I maintain my own Jenkins jobs), I find that Conventional Commits get the job done, so I can focus on other things. There could be better ways, but I have more pressing problems than demand my attention, with higher priority than optimizing my CICD configurations. [0]: https://github.com/conventional-changelog/standard-version https://github.com/conventional-changelog/standard-version [1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
        arethuza 7y ago
        [1] has: "or appends a ! after the type/scope, introduces a breaking API change"
    - bluejekyll 7y ago
      So why not just use patch, minor, major? Then we don’t even need the indirection. Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.
  - eyegor 7y ago
    > the usual 50 character limit. People do this? I guess it's fine if your commits are <100 lines of code but it seems needlessly concise, to the point of losing information. Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I refuse to tell them about commit -m because I feel it leads to undocumented history when you need to audit code. disclaimer: I tend to work on long lived projects (5+ years) Edit: bonus point that I forgot - by having a detailed commit log that reads like prose, it's easy to explain "everything you guys are working on" to the non technical folks.
    - TheDong 7y ago
      You're arguing against a strawman because you misunderstood the parent comment. The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long. For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large long-lived complex projects. Your argument against 50 characters in the entire message, including the body, is not one anyone would ever argue for, so you've constructed a complete strawman.
      - Vinnl 7y ago
        And some useful context: the 50-character limit is the result of the subject lines then being readable next to a commit graph that Git can display.
  - dmurray 7y ago
    Surely the most important part of a commit is the code committed, not the accompanying message.
    - iainmerrick 7y ago
      Yes and no. Both are important. The code is what actually gets run, sure, but good code with bad or misleading documentation can cause trouble later on. Commit messages are documentation.
      - cyphar 7y ago
        And commit messages are possibly the best form of documentation when it comes to debugging a problem -- it lets you know exactly what a developer was thinking when the code was written.
- greggman2 7y ago
  Why? Why is there such a strong desire for full sentences? It's pedantic to me. I'm completly fine with terse incomplete sentences. They are not harder to understand. Plus I work with international teams. Terse is often easier to write and understand for non-native speakers.
  - nirvdrum 7y ago
    I worked on an international team with non-native speakers and we found proper casing and punctuation easier to read.
  - deleted 7y ago
    [deleted]
  - greggman2 7y ago
    OCD seems prevalent in programmers. For me full sentence comment / commit message requirements are the ultimate process for the sake of process. Such a bikeshedding waste of time. Such policies serve absolutely no objective purpose. They're only there to satisfy some leader's asthetic senses and feeling of control. As for easier to read thousands of newspaper headlines and magazine article titles provide strong evidence otherwise. Even HN itself is proof it doesn't matter
nikolay 7y ago
I also dislike unnecessary abbreviations. "Feat" saves you just 3 characters, but earns you ugliness and confusion.
- spartanatreyu 7y ago
  It seems like it was made by someone who accidentally spilt coffee on their keyboard which made their 'U' key sticky. I like my "Feature" much more than "feat". This is my default commit message that I edit to contain what I want: <Type>: <Description> # Type can be: # - Feature: A new feature # - Bugfix: A bug fix # - Docs: Documentation only changes # - Styling: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) # - Refactor: A code change that neither fixes a bug nor adds a feature # - Performance: A code change that improves performance # - Tests: Adding missing tests # - Chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
  - nikolay 7y ago
    Nice! "Styling" could be ambiguous though. I personally use "Formatting" instead.
    - mdtusz 7y ago
      I typically go with "Linting". "Formatting" could mean something different in some contexts.
      - nikolay 7y ago
        That's even a better choice. Thank you!
inlined 7y ago
Probably because tools like github truncate large titles
sfink 7y ago
Tha i wha I cam her t writ a wel. D w reall nee t repea th infamou Uni mistak wit th "creat" syscal? Thin o th childre!
magicalhippo 7y ago
Because it makes you feel good from sounding like you've just accomplished a feat when you commit the feature.
JMTQp8lwXL 7y ago
Commit messages should be short. If you're familiar with conventional commit syntax (and chances are, your team will tell you to follow it, if your repository follows it), then your mind will automatically expand 'feat' to 'feature'.
munk-a 7y ago
`feat` is only a saver over `feature` if you're making a descriptor that was optional into something required - I admit I've never worked with a public commit history but for our internal projects commit messages are expected to give some justification or explanation of the necessity of the change without any formatting specifically enforced (though we require branches to contain at least one commit that pulls in the related issue ticket #). I much prefer encoding structured information like this at the ticket level where history can be more easily corrected and items are expected to be visible for all of time.
dvcrn 7y ago
Titles of commit messages should be short and concise, any extra information can go into the body of the commit. A common guideline is to have the title capped at 50 characters. If you work on the CLI, having a concise git log is far easier to skim than having very long commit messages and if I want to know more about the commit, I will check the body. It's also what a lot of websites use to truncate the title. From my experience, a few characters less do matter (which is also why I dropped conventional commits and just use "Add blah blah to blah", "Fix typo in user-facing message").
Svoka 7y ago
And only saves you like 3 symbols. Made a pull request fixing it https://github.com/conventional-commits/conventionalcommits.org/pull/204 https://github.com/conventional-commits/conventionalcommits....
- vemv 7y ago
  You're not saving them any work by creating that PR. That's better discussed and agreed on in advance.

ChristianBundy 7y ago

And while we're at it, why don't we just use full sentences? Before: > feat: allow provided config object to extend other configs After > Add option for config object to extend other configs I know this isn't the point of changelogs, but I've been using the verbs from KeepAChangelog to start my commit messages and it's been going well so far. > Add template preview to status page > Change textarea to increase height on `:focus` > Remove deprecated CLI flags > Fix margin styles causing layout problems

YorickPeterse 7y ago
I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messages. Setting that aside, the conventional commit "standard" (https://xkcd.com/927/ https://xkcd.com/927/) doesn't focus on what I think is the most important aspect of a commit: a good commit subject and message. In fact, prefixing the subject line with certain tags limits the amount of characters you have for writing the message; assuming you want to stick with the usual 50 character limit.
- JMTQp8lwXL 7y ago
  > feature/bug/etc is not particularly useful It's useful for automatically determining the next semantic release version by inspecting the commit history alone. fix: <-- patch feat: <-- minor breaking: <-- major
  - munk-a 7y ago
    That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.
    - JMTQp8lwXL 7y ago
      I was explaining how standard-version [0] works. Conventional Commits homepage doesn't mention anything about the '!' syntax. [1] I'm unsure if you're suggesting that's how you think it should work, or how it actually works. I haven't ever tried using the '!' syntax, so I can't say for certain. In terms of release management, it makes configuring CI jobs simpler with one less parameter. If you automatically release merges to master, you can use standard-version with conventional commit syntax. On other projects, I've seen people use GitHub PR labels to mark 'major', 'minor', or 'patch' releases (the CI system reads this information when generating releases). If you feel it's inappropriate for this information to live in your commit history, you'll need to specify it through one of these other options. Since I don't have a dedicated team for this sort of infrastructure (I maintain my own Jenkins jobs), I find that Conventional Commits get the job done, so I can focus on other things. There could be better ways, but I have more pressing problems than demand my attention, with higher priority than optimizing my CICD configurations. [0]: https://github.com/conventional-changelog/standard-version https://github.com/conventional-changelog/standard-version [1]: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
      - arethuza 7y ago
        [1] has: "or appends a ! after the type/scope, introduces a breaking API change"
  - bluejekyll 7y ago
    So why not just use patch, minor, major? Then we don’t even need the indirection. Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.
- eyegor 7y ago
  > the usual 50 character limit. People do this? I guess it's fine if your commits are <100 lines of code but it seems needlessly concise, to the point of losing information. Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I refuse to tell them about commit -m because I feel it leads to undocumented history when you need to audit code. disclaimer: I tend to work on long lived projects (5+ years) Edit: bonus point that I forgot - by having a detailed commit log that reads like prose, it's easy to explain "everything you guys are working on" to the non technical folks.
  - TheDong 7y ago
    You're arguing against a strawman because you misunderstood the parent comment. The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long. For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large long-lived complex projects. Your argument against 50 characters in the entire message, including the body, is not one anyone would ever argue for, so you've constructed a complete strawman.
    - Vinnl 7y ago
      And some useful context: the 50-character limit is the result of the subject lines then being readable next to a commit graph that Git can display.
- dmurray 7y ago
  Surely the most important part of a commit is the code committed, not the accompanying message.
  - iainmerrick 7y ago
    Yes and no. Both are important. The code is what actually gets run, sure, but good code with bad or misleading documentation can cause trouble later on. Commit messages are documentation.
    - cyphar 7y ago
      And commit messages are possibly the best form of documentation when it comes to debugging a problem -- it lets you know exactly what a developer was thinking when the code was written.
greggman2 7y ago
Why? Why is there such a strong desire for full sentences? It's pedantic to me. I'm completly fine with terse incomplete sentences. They are not harder to understand. Plus I work with international teams. Terse is often easier to write and understand for non-native speakers.
- nirvdrum 7y ago
  I worked on an international team with non-native speakers and we found proper casing and punctuation easier to read.
- deleted 7y ago
  [deleted]
- greggman2 7y ago
  OCD seems prevalent in programmers. For me full sentence comment / commit message requirements are the ultimate process for the sake of process. Such a bikeshedding waste of time. Such policies serve absolutely no objective purpose. They're only there to satisfy some leader's asthetic senses and feeling of control. As for easier to read thousands of newspaper headlines and magazine article titles provide strong evidence otherwise. Even HN itself is proof it doesn't matter

nikolay 7y ago

I also dislike unnecessary abbreviations. "Feat" saves you just 3 characters, but earns you ugliness and confusion.

spartanatreyu 7y ago
It seems like it was made by someone who accidentally spilt coffee on their keyboard which made their 'U' key sticky. I like my "Feature" much more than "feat". This is my default commit message that I edit to contain what I want: <Type>: <Description> # Type can be: # - Feature: A new feature # - Bugfix: A bug fix # - Docs: Documentation only changes # - Styling: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) # - Refactor: A code change that neither fixes a bug nor adds a feature # - Performance: A code change that improves performance # - Tests: Adding missing tests # - Chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
- nikolay 7y ago
  Nice! "Styling" could be ambiguous though. I personally use "Formatting" instead.
  - mdtusz 7y ago
    I typically go with "Linting". "Formatting" could mean something different in some contexts.
    - nikolay 7y ago
      That's even a better choice. Thank you!

inlined 7y ago

Probably because tools like github truncate large titles

sfink 7y ago

Tha i wha I cam her t writ a wel. D w reall nee t repea th infamou Uni mistak wit th "creat" syscal? Thin o th childre!

magicalhippo 7y ago

Because it makes you feel good from sounding like you've just accomplished a feat when you commit the feature.

JMTQp8lwXL 7y ago

Commit messages should be short. If you're familiar with conventional commit syntax (and chances are, your team will tell you to follow it, if your repository follows it), then your mind will automatically expand 'feat' to 'feature'.

munk-a 7y ago

`feat` is only a saver over `feature` if you're making a descriptor that was optional into something required - I admit I've never worked with a public commit history but for our internal projects commit messages are expected to give some justification or explanation of the necessity of the change without any formatting specifically enforced (though we require branches to contain at least one commit that pulls in the related issue ticket #). I much prefer encoding structured information like this at the ticket level where history can be more easily corrected and items are expected to be visible for all of time.

dvcrn 7y ago

Titles of commit messages should be short and concise, any extra information can go into the body of the commit. A common guideline is to have the title capped at 50 characters. If you work on the CLI, having a concise git log is far easier to skim than having very long commit messages and if I want to know more about the commit, I will check the body. It's also what a lot of websites use to truncate the title. From my experience, a few characters less do matter (which is also why I dropped conventional commits and just use "Add blah blah to blah", "Fix typo in user-facing message").

Svoka 7y ago

And only saves you like 3 symbols. Made a pull request fixing it https://github.com/conventional-commits/conventionalcommits.org/pull/204 https://github.com/conventional-commits/conventionalcommits....

vemv 7y ago
You're not saving them any work by creating that PR. That's better discussed and agreed on in advance.