Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conventional Commits: A specification for structured commit messages

conventionalcommits.org

Post reply on HN
Print view View original

51–60 of 99 posts

Re: Conventional Commits: A specification for structured commit messages

#51

Post by hakre »

nirvdrum wrote: post #41
abtinf wrote: post #19

I’ve found the commit message guidelines at https://git-scm.com/book/en/v2/Distributed-Git-Contributing-... to very helpful for clarity. “ The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that des…

50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.

the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).

Re: Conventional Commits: A specification for structured commit messages

#52

Post by Pfhreak »

skrebbel wrote: post #47
_glsb wrote: post #45

Imagine the following future: “Have you linted and unit tested your commit message?” “Junior Developer wanted. 10 years of Conventional Commits experience required.” “Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)” Something tell…

On come on, this entire "spec" can be summarized in two sentences. It can be validated with a 13 character regex. I share some of your sentiment though: I feel like the biggest reason to enforce a style like this is not for "machine readable commit messages" (I mean, why? ), but to encourage people to split refactors and features in separate commits. This makes it easier to understand what's going on later. I think t…

You ever play or work on a game? Changelogs are a big deal over there. Automatically collecting them would be highly valuable.

Re: Conventional Commits: A specification for structured commit messages

#53

Post by vemv »

prefixes such as "fix: " are better expressed at the bottom of the commit message body.

They are metadata, and as such they shouldn't take more attention than the actual data.

This matters when you are in a bug hunt in production - you want to find the culprit commit as efficiently as possible, without distractions.

Re: Conventional Commits: A specification for structured commit messages

#54

Post by vemv »

Svoka wrote: post #50
house9-2 wrote: post #3

> 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?

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

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

Re: Conventional Commits: A specification for structured commit messages

#55

Post by wincent »

skrebbel wrote: post #47
_glsb wrote: post #45

Imagine the following future: “Have you linted and unit tested your commit message?” “Junior Developer wanted. 10 years of Conventional Commits experience required.” “Download Conventionalizer! Now you can write Conventional Commits in plain English, having all the syntax automatically generated! (node, erlang OTP and Jerry’s pre-alpha TensorFlow binding library required. Windows support coming soon.)” Something tell…

On come on, this entire "spec" can be summarized in two sentences. It can be validated with a 13 character regex. I share some of your sentiment though: I feel like the biggest reason to enforce a style like this is not for "machine readable commit messages" (I mean, why? ), but to encourage people to split refactors and features in separate commits. This makes it easier to understand what's going on later. I think t…

> Why?

The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).

Re: Conventional Commits: A specification for structured commit messages

#56

Post by dgellow »

Pfhreak wrote: post #52
skrebbel wrote: post #47

Earlier quoted context omitted.

On come on, this entire "spec" can be summarized in two sentences. It can be validated with a 13 character regex. I share some of your sentiment though: I feel like the biggest reason to enforce a style like this is not for "machine readable commit messages" (I mean, why? ), but to encourage people to split refactors and features in separate commits. This makes it easier to understand what's going on later. I think t…

You ever play or work on a game? Changelogs are a big deal over there. Automatically collecting them would be highly valuable.

Do this from your JIRA (or equivalent) tickets then, you already have user oriented descriptions there. you can easily collect all tasks and bug tickets done during a sprint and generate a changelog. Though in practice I would expect someone to cleanup by hand.

Re: Conventional Commits: A specification for structured commit messages

#57

Post by [deleted] »

greggman2 wrote: post #37
jhardy54 wrote: post #7

Earlier quoted context omitted.

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…

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.

[deleted]

Re: Conventional Commits: A specification for structured commit messages

#58

Post by boudin »

bluejekyll wrote: post #38
JMTQp8lwXL wrote: post #18

Earlier quoted context omitted.

> 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: feat: breaking: <-- major

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.

In this case you suppose to add a ! after fix: fix! By using patch, minor and major you lose some information (the purpose of the commit)

Re: Conventional Commits: A specification for structured commit messages

#59

Post by hoseja »

hakre wrote: post #51
nirvdrum wrote: post #41

Earlier quoted context omitted.

50 chars seems pretty arbitrary to me. I'd rather have a useful commit message. I've seen some pretty contorted messages conveying no real info in order to meet an imaginary character limit.

the 50 chars is for the subject. the commit message (body) has no character limit (apart from a character limit per line).

It's still overly restrictive and ossified from terminals / email subjects or whatever.

Re: Conventional Commits: A specification for structured commit messages

#60

Post by dmurray »

YorickPeterse wrote: post #14
jhardy54 wrote: post #7

Earlier quoted context omitted.

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…

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 messag…

Surely the most important part of a commit is the code committed, not the accompanying message.
Post reply on HN