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

211–220 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#211

Post by dualvariable »

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.

I didn't abandon it, it was run by a different team, and we were one consumer of it. When the organization switched from Jira to GH issues the Jira was kept running for years, but nobody got the information into GH issues. Eventually the Jira was shut down, certainly by the time the company got acquired.

Re: Conventional Commits encourages focus on the wrong things

#212

Post by epmatsw »

jibcage wrote: post #45
mh-cx wrote: post #13

My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…

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.

Re: Conventional Commits encourages focus on the wrong things

#213

Post by Groxx »

Terr_ wrote: post #201
Groxx wrote: post #179

Earlier quoted context omitted.

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…

The next iteration is "smart tabs", where indents are stored as spaces in files for consistency, but when using an editor it recognizes that something special is going on, and offers you a tab-like experience.

which they kinda already do, yea. I just want it to be stronger, and to correct indentation that doesn't follow your formatting rules (which I have not seen / is not widespread). kinda like a `gofmt` overlay on a file, rather than modifying the file directly.

as a bonus, this could also make `goto fail;` errors more obvious.

Re: Conventional Commits encourages focus on the wrong things

#214

Post by amadeuspagel »

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 everything into a specific format this information is lost. There's a reason we have formats like markdown and plaintext, not just JSON.

Re: Conventional Commits encourages focus on the wrong things

#215

Post by chrisweekly »

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…

Given a choice between (spaces) and (mix of tabs and spaces) -- these being the only two options IRL -- it's not hard to see why spaces won.

Re: Conventional Commits encourages focus on the wrong things

#216

Post by SOLAR_FIELDS »

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.

It’s the linting argument all over again. I don’t give a shit what the style is. I give a shit that it’s consistent. Form whatever opinion you want about how you want to format your code, structure commit messages etc. I don’t really care, if you want to start every commit with “poop(fix): pooper my commit message”, as long as you’re consistent about it and enforce it programmatically you have my emphatic support

This comment assumes you are picking between a conventional commit message or something better. But the reality is you are almost always picking between a conventional commit and Nothing.

Re: Conventional Commits encourages focus on the wrong things

#217

Post by lelandfe »

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…

3 years later. You are working on some old project that apparently is erroring.

Through a git bisect, you find a commit that references JIRA, though your company uses Linear.

You sigh, and start reading the diff.

(Adapted from real life events)

Re: Conventional Commits encourages focus on the wrong things

#218

Post by andrybak »

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…

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 code-level questions. Commit messages are useful both during the review and when a future maintainer is reading the code.

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

Different commits do different things, so require different justifications. Here's a fictional example to demonstrate:

First commit:

    [PRJ-123] Server: extract class Foo
    
    In the next commit, we're going to need to re-use the foo logic from
    class Bar. Extract new class Foo from Bar to make it available for
    re-use.
Second commit on the same ticket

    [PRJ-123] Server: use Foo in Baz
    
    The users of BazClient need to be able to see foo information in the
    baz dialog.  Include Foo in the data sent by class Baz in the server.
Side note: the user might not even know that they are looking at Foo and Baz, it might be called something else in the UI they are shown. Whether or not this needs to be included in the commit message depends on the situation.

And later in a commit fixing a bug:

    [PRJ-456] Server: check ID for null in Foo
    
    When class Foo was extracted from Bar in commit deadbeef ([PRJ-123]
    Server: extract class Foo, 2026-06-06), a null check for the field
    ID got lost by accident.
    
    Check the field ID for null in class Foo to avoid a
    NullPointerException when a foo event is sent to Baz.

Re: Conventional Commits encourages focus on the wrong things

#219

Post by jeremyjh »

osigurdson wrote: post #75

I'd much rather people think deeply about summarizing their work. This helps others understand it but, more importantly, helps the developer understand what they did. If its hard to summarize, maybe it should be tightened up a little for instance. Enforcing a "schema" might help a tiny bit but also can cause people to check out a little as it can feel like just another meaningless process.

Exactly. People latch onto these perfunctory standards because it’s easier than understanding and clearly communicating the work they’ve done.
Post reply on HN