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

281–290 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#281

Post by codethief »

epmatsw wrote: post #212
jibcage wrote: post #45

Earlier quoted context omitted.

I personally prefer including issues as git trailers: fix thing in foo Issue: ABC-123 Git has plenty of builtins for parsing and formatting these trailers, so you can easily create custom git log aliases that let you see them inline and parse them for use with CI.

I think you’re the first person in this comment section to mention this. Git has a structure for machine-readable structured data. Put it there, not in free text fields for humans.

That's all good and well but the UX sucks. I usually have dozens of commands like

  git commit -m "PROJECT-XXXX Foo the bar to baz the qux"
in my shell history, which means 1) I can easily create follow-up commits under the same ticket number (no having to type the ticket number again), 2) I don't have to keep remembering the ticket number once I created the first commit on the given ticket. I'm sure I could set up an elaborate set of shell scripts and git aliases to auto-insert a ticket number as structured data at the bottom of each of my commits. But good luck convincing the rest of your team to do that.

Also, having the ticket number in the subject line means every git-related tool I use will always display it (even if the rest of the message gets cut off).

Re: Conventional Commits encourages focus on the wrong things

#282

Post by jeremyjh »

c-hendricks wrote: post #275
jeremyjh wrote: post #226

Earlier quoted context omitted.

How does typing “fix:” or “feat:” get you a step closer to being thoughtful?

To be honest I'm not really sure. I'm also not really sure how tipping "fix:" or "feat:" means people are not understanding their work and performing perfunctory actions though.

It doesn't force that, but it gives them an out. They can type "fix: frobnicator bug" and think they've written a good commit message because it meets the standard.

Re: Conventional Commits encourages focus on the wrong things

#283

Post by beart »

BoingBoomTschak wrote: post #125
xena wrote: post #121

Earlier quoted context omitted.

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.

Most of the folks I caught pushing "changes" as a commit message are now letting AI write their commit messages for them. It has been a massive improvement.

Re: Conventional Commits encourages focus on the wrong things

#284

Post by beart »

hn_throwaway_99 wrote: post #267
scuderiaseb wrote: post #243

Earlier quoted context omitted.

Great perspective! As a sidenote, I really like json5 for everything that would be needed for a human to read and it has great support everywhere. It fixes so many of JSONs shortcomings like comments. Edit: forgot the link if anyone’s interested https://json5.org/

Agreed, I really feel JSON5 should just be the default standard. But the fact that it's still not means it can't be used in a bunch of places where it would be an obvious improvement, for example, in package.json files - and fwiw I don't understand the NPM team's objection to using it.

As long as the file extension changes to align with the format, that sounds great. There are far too many abuses of .json that allow comments, trailing commas, etc.

Re: Conventional Commits encourages focus on the wrong things

#285

Post by beart »

yifanl wrote: post #176
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…

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

The compromise is to defer to a standard formatting tool such as prettier or pip8.

Re: Conventional Commits encourages focus on the wrong things

#286

Post by chickensong »

procaryote wrote: post #271
chickensong wrote: post #140

Earlier quoted context omitted.

Making an opinionated absolute statement about something that's widely used and argued about isn't even logical. If nobody got any benefit, it wouldn't be a thing. The CC standard may not be for everyone, but having some convention is often helpful. git log --pretty=oneline of structured format gives you broad filtering that's useful. Just writing like a human doesn't give you that ability and you're forced to read e…

Can you give an example of something useful you get from commits following the CC convention?

I gave an example right there in my previous comment (log filtering). To expand: our eyes and brains are good at pattern matching. Looking at git log --pretty=oneline with a structure lets you discard any commits irrelevant to what you're looking for without much cognitive effort (e.g. if I'm interested in a code change, I can discard any commit that starts with "docs"). You don't have to read entire lines, only scan the first few characters, or have grep do it for you.

Another example is basic metrics stored right there in git. Did changing your testing strategy result in less follow up fixes after feature deployment? You can get that signal with a shell | pipe one-liner.

Honestly I'm not die-hard CC convention, but I think it's better than nothing, which is what the person I was responding to was suggesting. If you're using an issue tracker, having a convention to prefix or trailer the commit with the issue ID is the highest value IMHO. The point is having some convention to get teams on the same page and assist with git meta work.

Re: Conventional Commits encourages focus on the wrong things

#287

Post by yencabulator »

sharts wrote: post #276
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.

But it does enforce a minimum quality

Form != quality, as LLMs will happily demonstrate.

Re: Conventional Commits encourages focus on the wrong things

#288

Post by bluGill »

sokoloff wrote: post #279
bluGill wrote: post #277

Earlier quoted context omitted.

They have the data but the numbers restarted at 1 and search in the new system isn't good. I think they all agree the old system was better - but the new license terms were unacceptable so we left anyway.

Restarting at 1 makes sense only if you think you’re going to run out of integers. I can’t fathom why part of the deployment of the new system wasn’t to re-seed to the current ticket number or an easy-to-remember integer (hopefully via database, but also ok even if via a Selenium for loop to pull 19,999 tickets to burn the numbers in the new system).

Different systems have different ways of working. some have one number some start at 1 for different types of tickets. A bug and a new feature have a number of differences.

Re: Conventional Commits encourages focus on the wrong things

#289

Post by daveisfera »

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…

"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup

Re: Conventional Commits encourages focus on the wrong things

#290

Post by adammarples »

procaryote wrote: post #269
adammarples wrote: post #100

Earlier quoted context omitted.

Pretty much everywhere I've worked recently enforces some kind of jira ticket number in the PR title

Perhaps it's useful to ask why? What does the jira ticket give you that a longer PR message can't do better?

Saves you a click maybe, at least it's easy to always know what ticket you're working on right in the terminal
Post reply on HN