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

91–100 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#91

Post by compiler-guy »

Benjamin_Dobell wrote: post #85
what wrote: post #82

Earlier quoted context omitted.

Use some convention for git trailers then. Having “fix” or “feat” in the commit title does not provide any useful information to someone scanning the log.

How... how is this not obviously the absolute very most useful information? When I encounter a bug in a dependency of mine. Before I worry about submitting a PR, the very first thing I do is grab my version number and check the commit logs for fixes since my version number. If I'm trying to decide whether I should bother upgrading, I scan the log for new features. It's the title, not the details. The commit message b…

If one is writing trailers and custom formatters, then probably the information that the formatter uses should be even more structured that sticking it in the subject line.

Re: Conventional Commits encourages focus on the wrong things

#92

Post by willy1234x1 »

jadar wrote: post #20
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…

Personally, if I am skimming a change log that is already limited in characters, I don’t care about ‘XYZ-999999’ in the main commit message. It’s good to tag as a trailer but I’d much rather see what the commit did than the Jira issue it came from.

Yeah the ticket value falls off pretty quickly to me. If I pull that up and it's been a closed issue for years and code has been added, rewritten, people moved, and tons of other changes to where the ticket is just a historical artifact and doesn't need priority in the first line of the commit message.

Re: Conventional Commits encourages focus on the wrong things

#93

Post by willy1234x1 »

compiler-guy wrote: post #86
alanwreath wrote: post #39

Earlier quoted context omitted.

It’s very helpful to know the motivation for the commit and if that motivation was tied to a client contract/feature. Especially in cases where a commit affects multiple files or even just one file so that all commits can be grouped into a feature/contract.

COMPANY-1234 in the title doesn't tell the reader all that much about the the feature or motivation. It does tell the client, but I'm not seeing why that is better than having it in the description as a tag, or some other nice way of extracting it.

Least of all when that ticket is older and so much of the code and the company has changed too. Like sometimes useful historical context sure but worth putting in the first line of a commit? I put it in the body with a link to the ticket or tickets as a footer, if someone wants historical context it's there.

Re: Conventional Commits encourages focus on the wrong things

#95

Post by claytonjy »

layer8 wrote: post #73
beart wrote: post #68

Earlier quoted context omitted.

That's true, but depends on your workflow and release strategy. If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts. If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.

If you have actual dependents in a SemVer fashion, then this isn’t useful for those still on the prior version. What you’d rather do is decrement the major version again because it’s compatible with the prior version again. Those dependents who already upgraded to the interim version have to consider another breaking change regardless. And if you don’t have these kinds of dependents, then the versioning scheme isn’t…

release-please[0] allows you to do a manual version override in a commit, which would allow you to decrement the major version upon reverting a breaking change

I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch.

[0]: https://github.com/googleapis/release-please

Re: Conventional Commits encourages focus on the wrong things

#96

Post by andix »

jadar wrote: post #20
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…

Personally, if I am skimming a change log that is already limited in characters, I don’t care about ‘XYZ-999999’ in the main commit message. It’s good to tag as a trailer but I’d much rather see what the commit did than the Jira issue it came from.

It's totally fine to put the issue number somewhere at the end of the commit message, and not in line 1.

Most tools cross-link them as long as # is mentioned anywhere in the message. It's also useful the other way around, open an issue and see all associated commits.

Re: Conventional Commits encourages focus on the wrong things

#97

Post by pseudalopex »

zug_zug wrote: post #63
codybloem wrote: post #42

I quite dislike this style of writing titles. "Stop something". I seems very popular. It sounds very commanding and "I am definitely right about this". Why not write "In favour of something" or "A case against something" or something like that?

Not as bad as "considered harmful" imo but still mildly toxic. I think the point is taking one rando's personal preferences (I'd prefer we swap the order of A and B) and trying to make it sound like something more than it is.

> Not as bad as "considered harmful" imo but still mildly toxic. I think the point is taking one rando's personal preferences (I'd prefer we swap the order of A and B) and trying to make it sound like something more than it is.

Mildly toxic was the same but worse in my opinion.

Re: Conventional Commits encourages focus on the wrong things

#98

Post by SamuelAdams »

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

It is useful if you automate generating release notes. Then your notes are grouped by new features first, then bug fixes after. This makes it a little easier for non-technical uses to read.

Re: Conventional Commits encourages focus on the wrong things

#99

Post by jonathanlydall »

layer8 wrote: post #65
dotwaffle wrote: post #55

The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

Completely agree, the attitude implied by “chore” is very off-putting to me. As if the rest should all be marked “fun” or “indifferent”. That kind of emotional judgement doesn’t belong in a commit message.

I’ve never personally used the chore term, but it doesn’t bother me to see it and I don’t feel it has a negative connotation.

Cleaning my kitchen after a meal may be a chore, but it’s not an intrinsically bad or unpleasant experience most of the time, it’s just good hygiene and afterwards I have the satisfaction of things being clean. Not cleaning the kitchen feels way worse to me as it ultimately leads to other far more unpleasant situations.

Such it is with updating dependencies, it generally needs to be done, so it’s good to do it, but it’s in no way noteworthy, so chore describes it perfectly, to me it signals that: “it’s work that needed to be done, but not for a feature, functionality change or bug fix on this particular code base, so you’re unlikely to see much change”.

Re: Conventional Commits encourages focus on the wrong things

#100

Post by adammarples »

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
Post reply on HN