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

191–200 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#191

Post by compel2160 »

yolkedgeek wrote: post #151
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…

Sidenote: Although JSON is very common, I argue EDN is the best data format out there.

Curious: what are the primary advantages you see?

Re: Conventional Commits encourages focus on the wrong things

#192

Post by flexagoon »

jacobsenscott wrote: post #113
SebastianKra wrote: post #41

Earlier quoted context omitted.

yep. I'm on the fence about types generally, but "fix:" saves/standardizes a bunch of phrases like "fix an issue where", "prevent" or having to invert the message by describing the solution instead.

You never need to write "fix", or "prevent" if you write a good message. Nobody says "fixed the car by changing the flat tire" or "Go prevent engine wear by getting an oil change today. You say "Change the flat tire", or "Change the oil". You can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".

I disagree. I think the commit description should be "stop the engine wear", not "change the oil". I much prefer commit messages describing why you did the changes, because the explanation of what you did is already there - the code diff itself.

Re: Conventional Commits encourages focus on the wrong things

#193

Post by bfeynman »

From my own experience in big tech and various OSS things, the crux of this piece rests on this whole scope not being focal point misses that in general the other practice is making sure PRs have limited scope in general so it's marginalized, i.e. reducing blast radius or too big of a change at once by design is implied.

Re: Conventional Commits encourages focus on the wrong things

#194

Post by bfeynman »

olzhasar wrote: post #120
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…

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.

why is "solving" the issue somehow the bar? software engineering has more practices rooted in psychology than engineering, its a moving and ambiguous target. Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.

Re: Conventional Commits encourages focus on the wrong things

#195

Post by punkbit »

I stick with Conventional Commits as a standardised way for communicating changes. Most contributions in the form of open PRs are squashed before merging into base branches. A team member can commit as personally wished in the feature branch. I still use CC for my own sanity and I’m very glad I do comparatively to what usually find in others feature branch commit histories.

Without standards most developers I’ve seen are very careless.

I generally work with changesets to curate changes at the time of contribution in accordance to semantic versioning.

What’s great about CC is the simplicity.

Re: Conventional Commits encourages focus on the wrong things

#196

Post by NeutralCrane »

WorldMaker wrote: post #117
xg15 wrote: post #36

This entire essay is just about how it should be " " instead of " "?

The essay gives a bunch of reasons to drop the "type" altogether and just use " " as prefix. The type either doesn't really mean anything or is redundant when writing commit headlines as English sentences. In a message like "Prevent thing from happening" the verb "prevent" is already basically a synonym for "fix". Similarly "Add" or "Support" likely implies "feat"/"feature". To some extent the "type" is simply about…

> fix and refactor

Both fix and refactor are both verbs and nouns

Re: Conventional Commits encourages focus on the wrong things

#197

Post by Ferret7446 »

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, along with the "successful git branching model", are symptoms of the fact that devs overwhelmed with the flexibility of git and look to other people to define standards for them because they that lack the experience to do so for their own requirements.

Actually, this is also similar to classic OOP, where people use a contrived method of structuring their code.

Re: Conventional Commits encourages focus on the wrong things

#199

Post by omcnoe »

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.

Re: Conventional Commits encourages focus on the wrong things

#200

Post by [deleted] »

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…

[deleted]
Post reply on HN