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

141–150 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#141

Post by calvinmorrison »

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

fixes/feature labels help when generated semver and doing changelogs if you publish them externally or internally.

JIRA tickets can help to, its about giving context to why the commit exists.

I find the 'component' label most helpful in large monorepos.

Re: Conventional Commits encourages focus on the wrong things

#144

Post by theptip »

mmcnl wrote: post #131
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…

Who reads commit messages anyway?

Maybe more people if the contract is that it’s how you get your work into the release notes?

Re: Conventional Commits encourages focus on the wrong things

#145

Post by eikenberry »

mmcnl wrote: post #133
eikenberry wrote: post #130

Earlier quoted context omitted.

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

It is a good substitute. 1. Usually the commit message is often too short to capture the "why" adequately. 2. It is very beneficial to capture the why in one single source of truth, and that usually is not the Git commit message in a business context. Hate on Jira all you want, but if you capture the "why" there, you can add comments, view history, add rich context, link dependencies, add rich context, etc. Can't do…

My ire is more directed at github PRs than Jira... but the same basic idea applies. You want a single source of truth and you want that as close to the origin (the code) as possible. Your history, dependencies, etc. are all in git already and can be highlighted there if appropriate. For general comments, git notes covers that.

Business (ie. $work) will dictate whatever it wants and that is what get used but for anything I personally have control over, everything goes in the repo itself to prevent platform lock-in. For example, github's been going downhilll lately but all those projects with their history in PRs, etc. now needs to exfiltrate all that data somehow.

Re: Conventional Commits encourages focus on the wrong things

#146

Post by theptip »

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 don’t have a horse in the race, but the OP objections ring hollow to me.

- scope is important: true, but isn’t that derivable from the commit contents? An important sanity check on a diff is to look at the paths touched. (A “test” diff should not modify prod auth code.) but if you want to see this from —oneline, sure, I think feat(auth): is better than feat:

- wrong audience: I don’t agree. feat commits _should_ actually describe the product-facing changes. You _should_ curate a nice stack with your no-op refactor changes first, then your small new feature change atop. This is the most helpful thing to include in a diff comment. You should put anything technical in comments so they are not lost, “why I chose algorithm X” belongs in a comment or DECISIONS.md. These are all tedious things that only psychos bother doing in a commit history at a fast moving company, but on OSS projects I think it’s much more important to stash context in the commit messages.

Re: Conventional Commits encourages focus on the wrong things

#147

Post by steveklabnik »

bloppe wrote: post #139
olzhasar wrote: post #120

Earlier quoted context omitted.

Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.

Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous

Both of these things are discussed in the article. (changelogs and semver)

Re: Conventional Commits encourages focus on the wrong things

#149

Post by bluGill »

eikenberry wrote: post #130
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 eventu…

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.

Re: Conventional Commits encourages focus on the wrong things

#150

Post by bluGill »

mystifyingpoi wrote: post #132
dualvariable wrote: post #119

Earlier quoted context omitted.

This is the way we did it when we used JIRA. For GH issues you can always navigate back to the PR discussion (which should have linked issues and other pointers in it) from the commit. Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless. IMO that actually argues for tight coupling between your issue tr…

> we largely abandoned JIRA and years later the instance got turned off and deleted Sorry to be nitpicky, but why did you abandon a tool that contained a lot of valuable knowledge? That's not the fault of GH nor JIRA, that's your fault. At least you'd back up descriptions + comments from these JIRA sources.

I my case it was a different system that got bought out by (I won't say but your guess is likely correct) and the new license terms were unacceptable
Post reply on HN