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

A specification for adding human and machine readable meaning to commit messages

conventionalcommits.org

Post reply on HN
Print view View original

11–20 of 49 posts

Re: A specification for adding human and machine readable meaning to commit messages

#11

Post by superbaconman »

markrages wrote: post #5

The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…

> What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place.

Doesn't that belong in the code itself? Do we really want the intention of a change to sit under multiple levels of blame?

Re: A specification for adding human and machine readable meaning to commit messages

#12

Post by Supermancho »

jahsome wrote: post #9
markrages wrote: post #5

The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…

I've hit a couple shops in a row now where squashes are The Way. It's such a short-sighted and misguided policy. I don't understand what is so appealing about a linear commit history. It's a fabrication of reality, and I have never been grateful for it, only enraged. Why wouldn't you want to know what _actually_ happened? What is being gained besides an aesthetically pleasing "commits" tab on GitHub?

Branch merge commit message is where you want the meaningful message. The individual commits are more or less noise for the vast majority of developers (half of which are below average). A useful system accounts for the most common case and it's not on the individual commit level.

Re: A specification for adding human and machine readable meaning to commit messages

#13

Post by ivan_gammel »

There’s a common convention that starts commit message with ticket numbers. Why tickets are not mentioned in the spec? This context is more important.

Regarding choice of types: why „feature“ is shortened to „feat“? If there’s a type for feature, why another type is „fix“, not a „bug“? Semantically naming should be consistent.

Automatic relationship with semver is questionable. Fix can be a change in architecture that deserves major version. Implementation of non-functional requirements is not a fix, yet it does not introduce new features and thus not a minor version increment. These are just two examples where inferred version is not what it could be. Making possible explicit expression of intent would help, e.g. by adding some tag like [minor]. Example:

   „APP-143:fix:major - migrated from mongodb to postgres“

   „123456:new:patch — added logging of requests“

Re: A specification for adding human and machine readable meaning to commit messages

#14

Post by andrew_ »

jahsome wrote: post #9
markrages wrote: post #5

The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…

I've hit a couple shops in a row now where squashes are The Way. It's such a short-sighted and misguided policy. I don't understand what is so appealing about a linear commit history. It's a fabrication of reality, and I have never been grateful for it, only enraged. Why wouldn't you want to know what _actually_ happened? What is being gained besides an aesthetically pleasing "commits" tab on GitHub?

GitHub flow is a natural companion to squash merges as a rule.

Re: A specification for adding human and machine readable meaning to commit messages

#15

Post by ivan_gammel »

superbaconman wrote: post #11
markrages wrote: post #5

The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…

> What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place. Doesn't that belong in the code itself? Do we really want the intention of a change to sit under multiple levels of blame?

It’s called traceability of requirements and is important part of post-release QA. At any given moment of time it must be possible to understand the reason for change down to a single line of code.

Re: A specification for adding human and machine readable meaning to commit messages

#16

Post by curun1r »

nikolasavic wrote: post #2

I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages

I’ve found it’s too error prone to rely on developers remembering to use conventional commits. But when you use something like cocogitto [0], it makes writing compliant commit messages the path of least resistance. I’ve always liked the idea of conventional commits, but it never felt valuable in practice until I discovered the tooling to make it easy.

[0] https://github.com/cocogitto/cocogitto

Re: A specification for adding human and machine readable meaning to commit messages

#17

Post by morgante »

nikolasavic wrote: post #2

I thought this was interesting, anyone using this? Is the juice worth the squeeze? Full title: Conventional Commits A specification for adding human and machine readable meaning to commit messages

I used it extensively on https://github.com/terraform-google-modules. Maintaining up-to-date release notes on 50+ repos would be extremely time-consuming and error-prone without conventional commits.

Re: A specification for adding human and machine readable meaning to commit messages

#18

Post by zaroth »

ivan_gammel wrote: post #15
superbaconman wrote: post #11

Earlier quoted context omitted.

> What does that user need to hear? Not which file or subsystem was changed. But the reason there is a change in the first place. Doesn't that belong in the code itself? Do we really want the intention of a change to sit under multiple levels of blame?

It’s called traceability of requirements and is important part of post-release QA. At any given moment of time it must be possible to understand the reason for change down to a single line of code.

That’s lovely and all, but can’t be a commit message, which is primarily about succinct human understanding and setting context.

A commit can certainly have computer readable metadata I presume!

Re: A specification for adding human and machine readable meaning to commit messages

#19

Post by dang »

Related:

Conventional Commits - https://news.ycombinator.com/item?id=30950377 - April 2022 (1 comment)

Conventional Commits - https://news.ycombinator.com/item?id=24208815 - Aug 2020 (23 comments)

Conventional Commits: A specification for structured commit messages - https://news.ycombinator.com/item?id=21125669 - Oct 2019 (95 comments)

Re: A specification for adding human and machine readable meaning to commit messages

#20

Post by vbezhenar »

jahsome wrote: post #9
markrages wrote: post #5

The examples given are more "what" changed than "why" it was changed. These are low-value commit messages because they are redundant with the content of the commit itself. It is almost like signing all your commits with your name or the current date. (Yes, I had a coworker who did this.) Better commit messages tell you what the situation was around the commit: Ticket number, or who wanted the change, or any other con…

I've hit a couple shops in a row now where squashes are The Way. It's such a short-sighted and misguided policy. I don't understand what is so appealing about a linear commit history. It's a fabrication of reality, and I have never been grateful for it, only enraged. Why wouldn't you want to know what _actually_ happened? What is being gained besides an aesthetically pleasing "commits" tab on GitHub?

Linear history is the only sane way to have usable history. Merge spaghetti is a good way to ensure that nobody would ever being able to navigate it.

Squashing large number of commits is questionable practice, though.

Post reply on HN