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

161–170 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#161

Post by hexasquid »

hn_throwaway_99 wrote: post #109

As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure , and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as goo…

Introducing JSON scoped comments, far superior to JSON conventional comments. People who use those are our rivals.

Re: Conventional Commits encourages focus on the wrong things

#162

Post by weinzierl »

I used and use Conventional Commits in private and professional projects and I think they have a place.

That being said, when I finally committed to using them something in me broke. Most of my career work was double faced. One face to the customer where you need to keep Tatemae under all circumstances (UI, Tickets, etc.). The other was the code and commit messages where you still kept your professionalism but you could be open and speak the language of your peers.

This time is over, maybe for good, but a tiny part of me misses it.

Re: Conventional Commits encourages focus on the wrong things

#163

Post by xigoi »

RVuRnvbM2e wrote: post #19

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

The article explains why this does not work properly.

Re: Conventional Commits encourages focus on the wrong things

#164

Post by gawa »

layer8 wrote: post #65
dotwaffle wrote: post #55

The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

Completely agree, the attitude implied by “chore” is very off-putting to me. As if the rest should all be marked “fun” or “indifferent”. That kind of emotional judgement doesn’t belong in a commit message.

You just made me realize why I've always considered 'chore' the most ambiguous type. In addition to being loosely defined ("transparent change with zero functionnal impact"?), this one is indeed a word related to emotion. No wonder it has a more subjective meaning than 'fix' or 'feat'.

This is why I never use it and almost always pick 'feat' to please the linter. Because I can't help considering that any change worth committing is improving the quality of the code in one way or the other, and thus a feature.

Re: Conventional Commits encourages focus on the wrong things

#165

Post by bluGill »

sokoloff wrote: post #157
bluGill wrote: post #149

Earlier quoted context omitted.

I find bug trackers and source control fad change several times over the life of my code. A number from a ticket system we no longer use is not helpful.

But a number from a ticket system you are using is helpful and vastly more log messages will be read during the time when it’s active than after it’s been retired/replaced.

The switch was too recent in my case, I'm still seeing many numbers from the old system that I can't look up.

Re: Conventional Commits encourages focus on the wrong things

#167

Post by IshKebab »

hebleb wrote: post #47
IshKebab wrote: post #18

Earlier quoted context omitted.

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.

If i'm looking at git history, the ticket number is the most useful piece of info to get more context on the changes for me

Ok... but why does it need to be in the title?

Re: Conventional Commits encourages focus on the wrong things

#169

Post by pseudalopex »

llimllib wrote: post #112
pseudalopex wrote: post #103

Earlier quoted context omitted.

Commit messages are good release notes rarely.

it's usually a "something is better than nothing" situation. If you have somebody willing to write custom release messages, that's definitely better; but conventional commits is better than nothing for it.

They did not say generated release notes are useful if you care so little you would write no release notes without them however.

Re: Conventional Commits encourages focus on the wrong things

#170

Post by IshKebab »

RVuRnvbM2e wrote: post #19

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

Why does that need to go in the title though? Just put some magic in the commit bodies, if you want to do versioning in that weird way. Then you aren't restricted to a single word either.
Post reply on HN