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

121–130 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#121

Post by xena »

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…

I end up thinking that conventional commits is a good idea because you can make tooling force people to at least put one iota of thought into what goes in a commit message. I've had to review so many commits with the subject "small fix" that was not in fact a small fix.

Re: Conventional Commits encourages focus on the wrong things

#122

Post by [deleted] »

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…

[deleted]

Re: Conventional Commits encourages focus on the wrong things

#123

Post by epage »

As a reviewer, I love type first because it sets expectations for what I'm going to look at. Similar if I'm bisecting or doing other history operations.

I don't do automated changelogs or versioning but it also makes it faster for me to do so.

I really dislike focusing on issue ids. I only want to jump to another tool if I need more information, so put it in the footer for after I've read what is there, like a front page news article giving you the option to go to the back to read more. Worst case that I've seen is people that think the Issue ID is all you need.

Re: Conventional Commits encourages focus on the wrong things

#124

Post by [deleted] »

xena wrote: post #121
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…

I end up thinking that conventional commits is a good idea because you can make tooling force people to at least put one iota of thought into what goes in a commit message. I've had to review so many commits with the subject "small fix" that was not in fact a small fix.

[deleted]

Re: Conventional Commits encourages focus on the wrong things

#125

Post by BoingBoomTschak »

xena wrote: post #121
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…

I end up thinking that conventional commits is a good idea because you can make tooling force people to at least put one iota of thought into what goes in a commit message. I've had to review so many commits with the subject "small fix" that was not in fact a small fix.

So now you'll get a lot of "fix: small", heh.

Re: Conventional Commits encourages focus on the wrong things

#126

Post by williamdclt »

gdevillers wrote: post #67
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...

I found an alternative word: "upkeep" Same idea without the pejorative aspect.

I wouldn't spend any sort of effort on this fight but that does seem quite a lot better

Re: Conventional Commits encourages focus on the wrong things

#128

Post by chickensong »

ralferoo wrote: post #57

The real takeaway is that different projects have different requirements. In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value.…

> Similarly "bug", "fix" or "feature" adds no useful value.

If you're not using/tied to an issue tracker, embedding tags like these in git gives you some basic metrics.

Re: Conventional Commits encourages focus on the wrong things

#129

Post by olivierlacan »

Keep a Changelog[0] maintainer here, weirdly seeing this while deep into work on way overdue 2.0 "release"[1], which should be out very soon.

I've had to contend with Conventional Commits both in the OSS world and at work as it proliferated from what seemed to me like robotic adoption by folks who were even loosely associated with the Angular ecosystem (remember that?).

I've always had a stance with KAC that folks trying to automate changelog creation (prior to LLM rise, mind you) were focusing on the wrong thing. I still think there's a fundamental difference in focus between what you write in a git commit and what you present in a changelog.

I know there are fundamental philosophical differences for folks who were used to HISTORY vs. NEWS vs. CHANGELOG but with the growing adoption of KAC-like CHANGELOG.md files and Release Notes (often not synonymous) I think we're thankfully past the weird era were maintainers dumped raw git log ranges between two tags and called that a changelog. I'm sure some still do it. But that's what Conventional Commits tries to replicate.

What's really odd to me is that this assumes (broadly) that every single commit in a repository is relevant to the eventual version release changelog (or release notes). Even if you assume some CC types get filtered and deprioritized from generated changelogs by some tools, it's still a huge miss on what communicating about a release typically means: these change likely matter to you as a package dependent or direct user, while others were omitted for good reason.

I'm trying to articulate that much more clearly in KAC 2.0 because there's a fundamental paradigm shift when a robot can now analyze recent work (yours or theirs) and craft changelog entries that appropriately shift the audience perspective from "git message for me/us in the future to understand this change" to "changelog entry for you/them to know what this group of changes means".

[0]: https://keepachangelog.com

[1]: https://github.com/olivierlacan/keep-a-changelog/pull/600 if anyone's curious and wants to get involved

Re: Conventional Commits encourages focus on the wrong things

#130

Post by eikenberry »

ralferoo wrote: post #57

The real takeaway is that different projects have different requirements. In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value.…

> The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.

The "why" is THE thing that needs to go in the git commit message. Capturing "why" is the entire point of that message and slapping a link to some external (and eventually absent) resource is not a good substitute.

Post reply on HN