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

151–160 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#151

Post by yolkedgeek »

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.

Re: Conventional Commits encourages focus on the wrong things

#152

Post by mckn1ght »

I like using conventional commits but I’ve often wondered if some sort of tagging/labeling using git-notes wouldn’t be better: https://git-scm.com/docs/git-notes

I’m just unsure that the short title is the ideal place to put this kind of tagging info: the kind of fix, and optionally, the relevant component(s). I find sometimes that can take up the majority of the title.

A forge could consume the git-notes and decorate a commit/pr accordingly. Heck, GitHub PRs already have a labeling system in place, just have to add some glue.

Re: Conventional Commits encourages focus on the wrong things

#154

Post by markbao »

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’m all for standardization but you could just use this argument to keep any suboptimal status quo in place. XML is good enough and a standard. SOAP is good enough and a standard. etc.

The claim is that Conventional Commits are good enough and standardized enough that having another structure isn’t really worth it. But “worth it” is subjective. I’d say that if you are making commits and reading PRs every work day, and the conventional commits format causes a little bit of friction, that friction can add up. Having another option other than seeing conventional commits as a law of nature gives options for teams who prefer it. (Most teams aren’t generating changelogs anyway.)

Re: Conventional Commits encourages focus on the wrong things

#155

Post by ralferoo »

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…

Respectfully, I disagree. A good commit message to me is something like:

[PRJ-123] Changed blah to foo

Blah didn't handle the wangle flange properly in some cases, foo is a better fit for customer requirements.

The "why" that justifies the change, is already contained in the JIRA ticket PRJ-123 and explains exactly what the customer requirement was that necessitated the change. It will almost certainly contain a lot of detail that isn't relevant to the commit message, because that isn't the place to be documenting customer requirements, and probably relates to a number of other tickets. Perhaps the code itself might have a comment explaining the code change, if it's a non-obvious implementation, but otherwise the ticket is the best place for that information.

Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.

Re: Conventional Commits encourages focus on the wrong things

#156

Post by ralferoo »

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.

You can trivially export your data from JIRA. If the parent experienced a situation where valuable information was lost because the instance was deactivated, that's not JIRA's fault.

Re: Conventional Commits encourages focus on the wrong things

#157

Post by sokoloff »

bluGill wrote: post #149
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…

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.

But a number from a ticket system you are using is helpful and vastly more log messages will be read during the time when it’s active than after it’s been retired/replaced.

Re: Conventional Commits encourages focus on the wrong things

#158

Post by stefan_ »

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 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" when having never understood Git to begin with. Peak bikeshed territory.

Re: Conventional Commits encourages focus on the wrong things

#159

Post by ralferoo »

oskarpearson wrote: post #138
mystifyingpoi wrote: post #132

Earlier quoted context omitted.

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

Like many tools defending their moats, tools like Jira don’t make it easy to get one’s data out.

That isn't true though. It's very easy to export your data from JIRA. From your board, go to the List tab, filter the items to whatever you want, and then click ... and you can export the data in various different formats. Exporting as XML dumps everything.

Re: Conventional Commits encourages focus on the wrong things

#160

Post by ralferoo »

llimllib wrote: post #112
pseudalopex wrote: post #103

Earlier quoted context omitted.

Commit messages are good release notes rarely.

it's usually a "something is better than nothing" situation. If you have somebody willing to write custom release messages, that's definitely better; but conventional commits is better than nothing for it.

Absolutely not. Commit messages should never be automatically passed through to the end-customer. I also worked in a place that tried it once and it was a disaster. Sure, a list of commit messages can be a useful start as a list of things that might want to be put in the release notes, but very rarely is the developer the right person to be explaining those changes to the end user.

If a developer is being asked to do that, it's a good sign that the PM isn't doing their job properly.

Post reply on HN