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

Conventional Commits encourages focus on the wrong things

sumnerevans.com

Post reply on HN
Print view View original

11–20 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#11

Post by karmakaze »

brzz wrote: post #4

“The audience of a changelog is entirely different than the audience for a commit log! A changelog is user-facing” I'd say that ship has probably sailed. Most companies are happy with “Bug Fixes & Performance Improvements”. At least if they're not going to put the effort in, then a generated changelog is better than nothing.

The best thing that I'd used for auto-updated software with weekly updates was to prefix user-facing visible commits with "uv:" Then each week we search for them and either use the text as-is or massage it slightly. We even got it into the product itself in the Help/Release-notes menu.

Funny to ask to stop doing something I don't do or never even heard of. I typically only mark database schema migrations or other major things with special prefixes.

Re: Conventional Commits encourages focus on the wrong things

#12

Post by chrismorgan »

I have long despised Conventional Commits for pretty much these reasons. Yes, it’s structure, but it’s not useful structure. Of the five things it claims to enable, three are nonsense and the other two are actively bad.

And it’s ugly.

(But I suppose I am talking primarily about the first line part. The “BREAKING CHANGE” bit is potentially actually useful, though being incompatible with git-interpret-trailers despite leaning on git-interpret-trailers for other footers seems a bit crazy.)

Re: Conventional Commits encourages focus on the wrong things

#13

Post by mh-cx »

My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something.

To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also felt that this habit is kind of standard - until i had to learn about "conventional commits".

I never got the hype.

Re: Conventional Commits encourages focus on the wrong things

#17

Post by chrismorgan »

akersten wrote: post #10

The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar'ing The whole idea of conventional commit is: > fix: [problem] so the correct conventional commit would be: > fix: foo bar'ing which is succinct and perfectly fine.

What you describe doesn’t match https://www.conventionalcommits.org/en/v1.0.0/>’s examples, or any practice I’ve ever seen.

> fix: prevent racing of requests

Though the example in the actual specification, “fix: array parsing issue when multiple spaces were contained in string”, is more inconclusive (and frankly doesn’t really make sense as a description).

Re: Conventional Commits encourages focus on the wrong things

#18

Post by IshKebab »

mh-cx wrote: post #13

My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…

Why do you even want the issue number in the commit title? I find that super annoying and unfortunately GitHub kind of forces it on you if you use merge queues.

It's fine for it to be in the description.

Re: Conventional Commits encourages focus on the wrong things

#19

Post by RVuRnvbM2e »

The thing conventional commits are really helpful for is continuous delivery. Every merge to main can be automatically tagged with semver and shipped because the thought that goes into tagging and versioning has already been done by the developers when they wrote the commit message.

I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.

Re: Conventional Commits encourages focus on the wrong things

#20

Post by jadar »

mh-cx wrote: post #13

My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…

Personally, if I am skimming a change log that is already limited in characters, I don’t care about ‘XYZ-999999’ in the main commit message. It’s good to tag as a trailer but I’d much rather see what the commit did than the Jira issue it came from.
Post reply on HN