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

41–50 of 294 posts

Re: Conventional Commits encourages focus on the wrong things

#41

Post by SebastianKra »

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.

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.

Re: Conventional Commits encourages focus on the wrong things

#43

Post by layer8 »

drfloyd51 wrote: post #28
Benjamin_Dobell wrote: post #24

Odd. The main reason to use this style of commit message is for CI/CD automation. EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies. The type of the commit informs the automated workflows how to handle the commit. This is why it comes first. For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version num…

No no. You see we need to get rid of conventional commits so AI can make commits easier.

I’m pleased to report that TFA is unrelated to AI.

Re: Conventional Commits encourages focus on the wrong things

#44

Post by chrishill89 »

Want machine-readable? Use the footers/trailers.

I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like a sentence. It also reads way better with just a sentence instead of three kinds of punctuation (:, (), !). Okay, I can tolerate an "area" in the subject. And that predates this conventio.

At my dayjob we make a webapp for non technical people. I can write a changelog for that just fine (in norwegian). The commit messages are irrelevant to the users. And demanding that all commits should be good enough for an end-user changelog? That's not happening for us anytime soon.

Use footers/trailers instead.

Re: Conventional Commits encourages focus on the wrong things

#45

Post by jibcage »

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.

Re: Conventional Commits encourages focus on the wrong things

#46

Post by d0mine »

nailer wrote: post #3

Asides from the well made points here ('scope is more important than type' etc). > something like fix, feat, chore, docs, or refactor 'Docs' are also part of the program, they need fixes too, and features need docs. If the docs don't match the features because they're not being updated when the code is, the docs are a lie and waste other developers time. Also if you were writing a standard: why would you randomly abb…

In practice, when conventional commits are used with git emojis, they look like “scope: what is done” already (“ scope: …”)

Re: Conventional Commits encourages focus on the wrong things

#47

Post by hebleb »

IshKebab wrote: post #18
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…

Why do you even want the issue number in the commit title ? I find that super annoying and unfortunately GitHub kind of forces it on you if you use merge queues. It's fine for it to be in the description.

If i'm looking at git history, the ticket number is the most useful piece of info to get more context on the changes for me

Re: Conventional Commits encourages focus on the wrong things

#48

Post by beart »

mcluck wrote: post #32
Benjamin_Dobell wrote: post #24

Odd. The main reason to use this style of commit message is for CI/CD automation. EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies. The type of the commit informs the automated workflows how to handle the commit. This is why it comes first. For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version num…

The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience

The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed.

Re: Conventional Commits encourages focus on the wrong things

#49

Post by voakbasda »

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?

Why not be direct and advocate clearly for the position that you prefer? You don’t have agree with their position, but asking them to water down their words is weak sauce.

Re: Conventional Commits encourages focus on the wrong things

#50

Post by agentultra »

Definitely agree that generating change logs from commits leads to confusing change logs for people that expect to see what changed between versions. A big long list of commits is too granular. A curated and summarized list of changes is much more in-line with what most people expect when reading a change log.
Post reply on HN