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

261–270 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#261

Post by monooso »

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.

I don't think it's reasonable to judge Conventional Commits on something it doesn't claim to do.

I can't see any suggestion on the CC site [^1] that it "solve[s] the core issue of the poor commit messages problem."

Rather, it's explicitly described as "a specification for adding human and machine readable meaning to commit messages."

I'd say it accomplishes that modest goal.

[^1]: https://www.conventionalcommits.org/en/v1.0.0/

Re: Conventional Commits encourages focus on the wrong things

#262

Post by atq2119 »

ralferoo wrote: post #155
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…

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…

Interesting to see somebody argue out in the wild for what I have been subjected to in the past and have long considered absolute worst practice.

It may be that my perspective is different because my work tends to be in "hard" foundational software (think OS components and programming language tool chains). It's not that customer requirements aren't a thing at all in that kind of work, but they tend to be far removed from the day-to-day and instead, mechanical sympathy rules supreme.

Commit messages need to focus on the software, not on the trappings of the process by which it evolves. Links to tickets can provide helpful context especially for bug fixes, but they belong in the commit message footer.

Your last paragraph is absolutely an anti-pattern at least in this work. If the implementation of a new feature is split over multiple changes, then surely there is something different and important to say about each of those changes. Does your split even make sense otherwise?

Re: Conventional Commits encourages focus on the wrong things

#263

Post by andrybak »

ralferoo wrote: post #251
andrybak wrote: post #218

Earlier quoted context omitted.

The difference is that the Jira ticket is for everyone involved in a project (business analyst, UI designer, QA, support, DBA), while commit messages are written with developers being almost exclusive audience. PRJ-123 might explain why an end user might need it, but the commit message explains why the change (diff) is the way that it is. The ticket answers requirements-level questions, the commit message answers cod…

Personal preference I guess, but to me all of those commit messages are way too wordy. I'd probably have: [PRJ-123] Refactor Foo out from Bar [PRJ-123] Include Foo data in BazClient [PRJ-456] Null-guard on Foo ID to avoid data loss Bug introduced in commit deadbeef And then in PRJ-456, I'd also have the comment about bug introduced in commit deadbeef, and link the two JIRAs if it was significant, or just mention it i…

Git is more robust than Jira. Git log is accessible offline. Jira descriptions exist only as long as people managing the Jira instance are competent and are migrating the necessary data correctly when migrations are needed. Even migrations from one Jira instance to another (e.g. when companies get acquired and two Jira servers get merged) can be extremely brittle.

It's fair that maybe such simple trivial changes don't deserve such a wordy commit message. But these are just fictional examples that I came up with on the spot. Refactorings, new features, and bugfixes can all have various levels of complexity.

A good commit message helps answer the "why?" questions first and foremost. If a diff is fairly large, pointing out the most important change can be useful. Explanations for non-trivial dataflow can sometimes not make sense in separate documentation, but still be relevant in a commit message.

Re: Conventional Commits encourages focus on the wrong things

#264

Post by rerdavies »

rerdavies wrote: post #198

I'm not getting why "scope" gets any priority at all. Are filenames not attached to a commit for those exceedingly rare cases where you're looking for which files are thrashing?

Also not getting the downvotes. It's not a rhetorical question; it's a question looking for an answer. If somebody could explain why "Scope" gets should get precious space in the title of a commit, I'd be grateful. It seems inconsistent with the reasoning used to remove other pieces of information. If "feature request" or "bug fix" doesn't make it into the commit title because it's usually apparent from the description, then surely the same is true for "scope".

Re: Conventional Commits encourages focus on the wrong things

#265

Post by hn_throwaway_99 »

amadeuspagel wrote: post #214
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…

> Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on. The big deal is not that scope is more important then type, the big deal is that natural language allows you to formulate things to emphasize whatever you consider important, and by forcing e…

Conventional Commits still have a free-form description section. The structure just introduces some standardized elements - and this is common in all types of written communication. Books have tables of contents, chapters have titles, letters have salutations, etc. etc.

Re: Conventional Commits encourages focus on the wrong things

#266

Post by hn_throwaway_99 »

markbao wrote: post #154
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, an…

The new structure needs to be "better enough" that it overcomes the built-in deficits of the older structure, and it can't introduce so many new problems that make it a net negative.

JSON was definitely a huge improvement in simplicity and readability compared to XML for many contexts. Similarly REST a much better option than SOAP (and all of these are examples of the general over-engineered, design-by-committee architectures that came out of the late 90s/early 00s - see also the original EJB spec - before a larger trend towards simplicity and ease of use won out).

But it this case, a lot of the differences just feel like potayto/potahto, i.e. minor stylistic preferences. And I have been in jobs where more than 50% of my time was doing code reviews, and while often there were e.g. some linter rules or whatever that I found suboptimal, it was a lot easier to just go with it than waste the energy to have the battle over why I think for loops are actually OK.

Re: Conventional Commits encourages focus on the wrong things

#267

Post by hn_throwaway_99 »

scuderiaseb wrote: post #243
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…

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.

Re: Conventional Commits encourages focus on the wrong things

#268

Post by procaryote »

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.

One of many problems introduced by monorepos

Re: Conventional Commits encourages focus on the wrong things

#269

Post by procaryote »

adammarples wrote: post #100
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.…

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?

Re: Conventional Commits encourages focus on the wrong things

#270

Post by procaryote »

jacobsenscott wrote: post #110
akersten wrote: post #10

The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar'ing The whole idea of conventional commit is: > fix: [problem] so the correct conventional commit would be: > fix: foo bar'ing which is succinct and perfectly fine.

None of this is as good as "free array memory before it goes out of scope". This is better than `fix: memory leak` - which is what most people would do. It's also better than `fix: free array memory...` because `fix:` is redundant when you have a good message. I get people want to build automation around this stuff, but just do that in a footer of a commit message where humans don't need to see it.

Arguably "fix memory leak" is why you free the array; freeing the array is just how you fixed it and less interesting as that is also in the diff
Post reply on HN