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

201–210 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#201

Post by Terr_ »

Groxx wrote: post #179
yifanl wrote: post #176

Earlier quoted context omitted.

Some programmers prefer 2 spaces, some programmers prefer 4, why don't we compromise and pick a number between 2 and 4?

hence tabs. just configure your display for the width you like. though I do wish more editors had some kind of "ignore the spacing, display it semantically like [this]" and just let you insert whatever you wanted, converted to whatever is nearby, and didn't touch lines you didn't create. there's no reason to even have the debate or care about inconsistencies, you can essentially always* convert between them losslessl…

The next iteration is "smart tabs", where indents are stored as spaces in files for consistency, but when using an editor it recognizes that something special is going on, and offers you a tab-like experience.

Re: Conventional Commits encourages focus on the wrong things

#202

Post by NeutralCrane »

This is the kind of thing where the extent to which people get worked up over it far exceeds the benefit of actually doing so.

Is it theoretically possible that people can write good commit messages without a framework? Yes. Does that work out in practice across entire teams? No. Any kind of a convention for commit messages is an improvement.

Beyond that, type > scope vs scope > type or whatever is splitting hairs. The juice of that debate is not worth the squeeze.

Re: Conventional Commits encourages focus on the wrong things

#203

Post by nailer »

d0mine wrote: post #46
nailer wrote: post #3

Asides from the well made points here ('scope is more important than type' etc). > something like fix, feat, chore, docs, or refactor 'Docs' are also part of the program, they need fixes too, and features need docs. If the docs don't match the features because they're not being updated when the code is, the docs are a lie and waste other developers time. Also if you were writing a standard: why would you randomly abb…

In practice, when conventional commits are used with git emojis, they look like “scope: what is done” already (“ scope: …”)

No. If you use ‘star’ for ‘feature’ that does not convey the extent of the change.

Re: Conventional Commits encourages focus on the wrong things

#204

Post by Izkata »

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?

I work with legacy code and am regularly reading commit messages from 10-15 years ago while figuring out what was going on several teams past. It's also why I'm against squash-merges, there have been plenty of times a commit was in the middle of a chain of commits and the helpful context would have been erased if we had squashes in svn.

Re: Conventional Commits encourages focus on the wrong things

#205

Post by Izkata »

dualvariable wrote: post #119
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.…

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…

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

We did Bugzilla -> FogBugz -> Jira. Almost all the data was lost every time, no one bothered with migration except for the maintenance project. Worse, even on Jira we lose cases as teams end and hand off the code, and the Jira project is closed so no one else can access it.

We've also done cvs -> svn -> git. All the commits have survived migration.

I do keep including cases in the commits messages, if nothing else it'll help link things together in the future, but never rely on them for context a future maintainer might need.

Re: Conventional Commits encourages focus on the wrong things

#206

Post by npstr »

SoftTalker wrote: post #177
stefan_ wrote: post #158

Earlier quoted context omitted.

I don't need a standard for this. This is just noise. There are some people who have some sort of mental ailment that makes them obsessively want to introduce "structure" "scheme" "patterns" where it is just innately nonsense. You do you, but stop trying to force it on people. Reminds me of the "scrum master" adjacent folks who could never cut it writing code and then branched into all kinds of things like "Git Flow"…

Reminds me of a place I worked at where a "naming committee" had to approve variable names. And no, you could not use "i" as an index in a one-line loop.

i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc

Re: Conventional Commits encourages focus on the wrong things

#208

Post by arcticfox »

omcnoe wrote: post #199
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.…

Scope is crucial when working with multiple teams/projects in a monorepo.

Exactly. I think it's funny / telling that my team analyzed Conventional Commits and came to the exact same conclusion the author did.

Scope might not be important to every project, but the feat/bug etc taxonomy might be the least useful focus of them all.

Re: Conventional Commits encourages focus on the wrong things

#209

Post by hambes »

the article mentions three types of stakeholders: contributors, debuggers and incident responders. it entirely fails to mentions consumers, who mostly care about backwards compatibility of changes, and thus about the type of a change. once the type is established, e.g. a change is breakimg, the consumer next cares about the scope to make downstream adjustments.

the part about broken promises regarding breaking changes is _kind of_ fair, but only assuming tooling isn't able to track reverts. accidental breakages occure with every approach and better to have an approximation than no information at all.

Re: Conventional Commits encourages focus on the wrong things

#210

Post by nemetroid »

npstr wrote: post #206
SoftTalker wrote: post #177

Earlier quoted context omitted.

Reminds me of a place I worked at where a "naming committee" had to approve variable names. And no, you could not use "i" as an index in a one-line loop.

i and j etc is bad though, but for a different reason than usually claimed. it's suboptimal because it's hard to search for. just use ii, jj, kk, etc

\
Post reply on HN