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

251–260 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#251

Post by ralferoo »

andrybak wrote: post #218
ralferoo wrote: post #155

Earlier quoted context omitted.

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…

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 in a comment for a minor fix.

For me personally, nothing else in your commit messages adds value that can't be seen trivially from glancing at the changes.

Re: Conventional Commits encourages focus on the wrong things

#252

Post by ralferoo »

bluGill wrote: post #165
sokoloff wrote: post #157

Earlier quoted context omitted.

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.

The switch was too recent in my case, I'm still seeing many numbers from the old system that I can't look up.

You should shout at your project managers then.

The data in the ticket system should be considered important as it's the primary interface through which developers, QA and design share information.

Re: Conventional Commits encourages focus on the wrong things

#253

Post by SebastianKra »

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

Whatever describes the change better. Sometimes the issue is easier to describe "fix: car steers in slalom". Where the solution would have been subtle interaction between 3 different components that only occurs in 3rd gear.

Re: Conventional Commits encourages focus on the wrong things

#254

Post by IshKebab »

andrybak wrote: post #228
IshKebab wrote: post #167

Earlier quoted context omitted.

Ok... but why does it need to be in the title?

if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is ve…

If the IDE supports that it can easily extract the issue number/link from the commit body too.

Re: Conventional Commits encourages focus on the wrong things

#256

Post by rlpb »

All the items being discussed are useful things to think about and cover in the commit message. Certainly if after reading a commit message I do not know what was intended (eg. “is this a refactor that is not intended to change behaviour or not?”) then the commit message is missing something. What I object to is overloading all of this into the first line. The subject should be reserved for the most relevant information and is limited in length. Forcing committers to collapse a bunch of metadata into it makes it less useful for that purpose.

Re: Conventional Commits encourages focus on the wrong things

#258

Post by mattrb »

steveklabnik wrote: post #147
bloppe wrote: post #139

Earlier quoted context omitted.

Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous

Both of these things are discussed in the article. (changelogs and semver)

They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.

Re: Conventional Commits encourages focus on the wrong things

#259

Post by shimman »

Merovius wrote: post #235
bfeynman wrote: post #194

Earlier quoted context omitted.

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.

> Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics. I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional co…

[flagged]

Re: Conventional Commits encourages focus on the wrong things

#260

Post by SoftTalker »

ajuc wrote: post #242
npstr wrote: post #206

Earlier quoted context omitted.

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

If you need to search for a variable named i - you should have named it something else (and no, jj is NOT an improvement in that case). One letter variables are supposed to be used in scopes that fit on the screen completely. You might as well search for "for" TL; DR: it's on purpose.

> One letter variables are supposed to be used in scopes that fit on the screen completely.

Exactly, and ideally in less space than that. If you have something like:

  for (i=0; i
There is no point in using a "descriptive" name for the index. It's completely obvious what's going on. Anything more verbose would just hamper readability.
Post reply on HN