25 ms·

Conventional Commits encourages focus on the wrong things

• m_m_carvalho 3mo ago
  As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago. Conventional commits are most valuable to me as historical context rather than as a release-management tool. The larger the project becomes, the more useful that context gets.
  • radlad 3mo ago
    This sounds like what regular commit messages do. How are conventional commits specifically helpful?
    • d0mine 3mo ago
      Conventional commits (especially with git emojis) show at a glance the blast radius of the change (eg whether it breaks the product itself or just some internal dev tools). Emojis help immensely when looking at dozens of commits at a time.
  • cperciva 3mo ago
    That information should still be in the commit messages. "No functional change intended." appears widely in FreeBSD commit logs when code is being refactored (or, rarely, restyled). And the issue isn't whether you can remember what you changed yesterday; this is largely about making sure other developers can quickly identify relevant commits. If you're a solo non-OSS developer, this is entirely relevant to you.
• nailer 3mo ago
  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 abbreviate 'feature' but not 'refactor'? That sounds like a nitpick but standards require great thought, this is a bit of a smell that there hasn't been much thought into designing 'conventional commits'. Finally: the name 'Conventional commits' is a land grab (reminds me of when someone made a JS Standard and called it 'StandardJS', ignoring every existing popular standard). From the article, the *actual* convention is 'scope: work" - Linux subsystem: description - FreeBSD prefix: description - Git area: description - Go package: description - nixpkgs pkg-name: description
  • d0mine 3mo ago
    In practice, when conventional commits are used with git emojis, they look like “scope: what is done” already (“<emoji> <issue-id> scope: …”)
    • nailer 3mo ago
      No. If you use ‘star’ for ‘feature’ that does not convey the extent of the change.
• brzz 3mo ago
  “The audience of a changelog is entirely different than the audience for a commit log! A changelog is user-facing” I'd say that ship has probably sailed. Most companies are happy with “Bug Fixes & Performance Improvements”. At least if they're not going to put the effort in, then a generated changelog is better than nothing.
  • karmakaze 3mo ago
    The best thing that I'd used for auto-updated software with weekly updates was to prefix user-facing visible commits with "uv:" Then each week we search for them and either use the text as-is or massage it slightly. We even got it into the product itself in the Help/Release-notes menu. Funny to ask to stop doing something I don't do or never even heard of. I typically only mark database schema migrations or other major things with special prefixes.
    • beart 3mo ago
      I like this idea, but could see it working better as a git trailer to avoid adding noise to git log
  • pancsta 3mo ago
    He confuses changelog with release notes. Doesnt know how to name commits and probably doesnt know how to name symbols either. Skill issue and he’s sad, now in public. Move on…
• shmerl 3mo ago
  I don't care much what it says as in "fix", "chore" etc, but for me the main benefit is breaking changes indicated with "<type>!", something like "feat!: ... ". This makes neovim plugin manager highlight the change differently which brings attention to it when you update stuff. So please do use it instead of complaining! I do like the suggestion of scope!: ... if it will be treated the same way with breaking changes reactions.
• lezojeda 3mo ago
  [dead]
• gdss 3mo ago
  [flagged]
  • rootnod3 3mo ago
    Elaborate?
• akersten 3mo ago
  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.
  • chrismorgan 3mo ago
    What you describe doesn’t match <https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/>’s examples, or any practice I’ve ever seen. > fix: prevent racing of requests Though the example in the actual specification, “fix: array parsing issue when multiple spaces were contained in string”, is more inconclusive (and frankly doesn’t really make sense as a description).
    • darknavi 3mo ago
      I agree, the default change logging using something like semantic-release would result in this, which feels way off: # Bug Fixes - foo bar'ing
  • SebastianKra 3mo ago
    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.
    • jacobsenscott 3mo ago
      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".
      • 3mo ago
• chrismorgan 3mo ago
  I have long despised Conventional Commits for pretty much these reasons. Yes, it’s structure, but it’s not useful structure. Of the five things it claims to enable, three are nonsense and the other two are actively bad. And it’s ugly. (But I suppose I am talking primarily about the first line part. The “BREAKING CHANGE” bit is potentially actually useful, though being incompatible with git-interpret-trailers despite leaning on git-interpret-trailers for other footers seems a bit crazy.)
• mh-cx 3mo ago
  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 felt that this habit is kind of standard - until i had to learn about "conventional commits". I never got the hype.
  • IshKebab 3mo ago
    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.
    • alanwreath 3mo ago
      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.
      • compiler-guy 3mo ago
        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.
        • willy1234x1 3mo ago
          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.
• IshKebab 3mo ago
  Couldn't agree more with this. The commit type tells me almost nothing and just wastes my time skipping over it. Scopes are way more useful.
  • voakbasda 3mo ago
    Many great developers seem to agree, based on the list of conventions use by the infrastructure scale projects covered in the article.
• deleted 3mo ago
  [deleted]
• skydhash 3mo ago
  Mine is “ticket id - Imperative phrase”. Then I write a “why” description of the changes if needs be. As for personal project, I quite like the scoped commits style.
• RVuRnvbM2e 3mo ago
  The thing conventional commits are really helpful for is continuous delivery. Every merge to main can be automatically tagged with semver and shipped because the thought that goes into tagging and versioning has already been done by the developers when they wrote the commit message. I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.
  • herpdyderp 3mo ago
    I do this on my OSS projects to automate semver bumps and it's amazing! At work, I also enforce "tags" (not git tags, just strings in the PR title) based on who cares about the change and then generate changelogs for the respective teams based on those "tags".
  • WorldMaker 3mo ago
    I like relying on `git tags` even in continuous delivery situations. `git describe` is often good enough for continuous delivery versioning `v1.2.3-4-gabcdef` can describe a commit exactly enough to make git happy and is semver-like enough to set expectations, even/especially if new `git tags` are only ever inserted on human discretion (this is breaking change so I need to tag a new major now). The only real debate with `git describe` format version numbering is if to better conform to semver expectations the first dash should be a plus or not and you can do that change with a quick regex if you feel it is worth it for whatever is enforcing your semver expectations (ordering versions correctly in a package manager, for instance). `git describe` is easy to automate for CD, but can leave version number decisions to people via `git tag` choices (and/or GitHub Releases) rather than trying to guess from commit history magic keywords.
  • xigoi 3mo ago
    The article explains why this does not work properly.
    • RVuRnvbM2e 3mo ago
      Yeah the article is wrong
• docheinestages 3mo ago
  I think some structure in commit messages is helpful, but not to the point where it gets in the way of effectively reflecting what the commit contains, why it was done, and any comments for future reference, e.g. potential regressions.
• Benjamin_Dobell 3mo ago
  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 number is incremented. If you commit a `feat: ` then it's a minor version is bump. `feat! ` is a major version bump. Even if you're not using CD for releases, semantic commit messages are sometimes used to automate change log generation. Granted, your change logs should not typically include the Git commit messages themselves — those are developer facing, not user facing.
  • drfloyd51 3mo ago
    No no. You see we need to get rid of conventional commits so AI can make commits easier.
    • layer8 3mo ago
      I’m pleased to report that TFA is unrelated to AI.
  • mcluck 3mo ago
    The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience
    • beart 3mo ago
      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.
      • 3mo ago
• sandstrom 3mo ago
  I totally agree. If one needs to put metadata in commits, usually better to just put it in a Git trailer. https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers `Co-authored-by: Alice` is a common one, but you can have anything in there.
• jmull 3mo ago
  There’s a much less awkward way to keep a change log: Keep a change log.
  • jsve 3mo ago
    I 100% agree. I found https://keepachangelog.com/en/1.1.0/ https://keepachangelog.com/en/1.1.0/ as I was writing the article which advocates for exactly this!
  • beart 3mo ago
    This is not without struggles. Many times the changelog updates are missed. You can try to catch this in code review, but that could also be missed. So you can try to automatically verify the changelog was updated, but you can't force that as a pass/fail check since not all changes require a user facing change. Or your project maintainers simply copy the commit message and paste it into the changelog, and at that point, why not just automate it with something like conventional commits? Could/should the changelog be considered a first-class deliverable with care and attention provided? I think so, but I'm not in a position to exert direct control over that across dozens of repos and team members.
    • CharlesW 3mo ago
      > Many times the changelog updates are missed. In my experience, LLMs are great at reviewing changelogs for potential gaps from a user POV (and even creating draft changelogs wholesale, if you're backfilling) based on git history.
• codingjoe 3mo ago
  I think any notation is use case specific and should be adapted to beat serve its domain. However, actually writing a good commit message is an art form few have mastered. I wrote a small natural language linter to teach my teams meaningful technical writing: https://github.com/codingjoe/word-weasel https://github.com/codingjoe/word-weasel
• flakiness 3mo ago
  I see more of these conventional commit-style comments recently and it feels like coming from Claude Code etc. It's a bit unsettling that not only training data but also random lines in the default system prompt affects this kind of software development norms in subtle and pervasive ways.
  • jsve 3mo ago
    I've seen Claude Code aggressively use Conventional Commits, even when the project its working on doesn't use them.
• skerit 3mo ago
  And then you have me, using gitmoji
• bowlofhummus 3mo ago
  I really dont care about commit messages. Just create strict rules for branches that contains issue nr + description, and squash all commits on merging the PR.
• xg15 3mo ago
  This entire essay is just about how it should be "<scope> <optional type>" instead of "<type> <optional scope>"?
  • WorldMaker 3mo ago
    The essay gives a bunch of reasons to drop the "type" altogether and just use "<optional scope>" as prefix. The type either doesn't really mean anything or is redundant when writing commit headlines as English sentences. In a message like "Prevent thing from happening" the verb "prevent" is already basically a synonym for "fix". Similarly "Add" or "Support" likely implies "feat"/"feature". To some extent the "type" is simply about trying to limit/standardize the number of possible "verbs" to start a commit headline with, in which case Conventional Commits made the mistake of mixing verbs and nouns (fix and refactor are verbs but feature and chore are nouns) and adding distracting punctuation where English prefers none between the Verb and its direct object in a "Verb the thing" sentence. "Verb: the thing" only ever really looks awkward. But also do we really want to limit the possible number of verbs that a headline sentence can start with when making commits? "Fix" and "Prevent" may often act like synonyms but there are connotative differences. In some cases "Prevent" may be a shorter way to explain why something needed to be fixed in a headline because "prevent" also says "stop a thing from happening that wasn't supposed to happen" whereas "fix" alone may not yield that extra context. The top line of a commit should be a short and sweet headline and sometimes the cleanest way to do that is to use the full gamut of English verbs at your disposal to tell the right story as quickly as possible.
    • NeutralCrane 3mo ago
      > fix and refactor Both fix and refactor are both verbs and nouns
      • WorldMaker 3mo ago
        In my experience both are more often in noun form with an article ("a fix" and "a refactor") because they are both sort of awkward alone. But sure I can appreciate that's probably how we got the set of words that we did that they were all picked as nouns and only in juxtaposition does it become more obvious to me that I think it might have been better to have picked just verbs. I can see the sorts of thoughts that led to "noun: verb the object" as a "good" headline format, especially when the "noun:" is considered the important part of the headline. But only before realizing it is generally redundant between "noun" and "verb" and "noun:" might not really be all that important (as the article points out flaws in).
• codybloem 3mo ago
  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?
  • voakbasda 3mo ago
    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.
    • chrystalkey 3mo ago
      Oh please. Public discussion is always a balance, and to answer your question: if the content is nuanced, the title should be too. If they mismatch some of your audience is unnecessarily put off. Ill add: I am personally put off in the same way your parent comment is, because hard stances are usually wrong, and I like a bit of nuance in my life.
  • some_furry 3mo ago
    https://knowyourmeme.com/memes/stop-doing-math https://knowyourmeme.com/memes/stop-doing-math There is a meme that inspires some of this genre of title, fwiw
  • lardissone 3mo ago
    I came to say something similar. I don't like conventional commits much neither, but let the people use whatever they want!
  • zug_zug 3mo ago
    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.
    • 3mo ago
• chrishill89 3mo ago
  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.
• agentultra 3mo ago
  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.
• dotwaffle 3mo ago
  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-patches.html#the-canonical-patch-format https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
  • jsve 3mo ago
    You might enjoy Rich's take: https://richvdh.org/conventional-commits-considered-harmful.html#chore-is-a-problematic-term https://richvdh.org/conventional-commits-considered-harmful....
    • embedding-shape 3mo ago
      Richard van der Hoff that is, not Rich Hickey which I first thought had published something new and opinionated again.
  • layer8 3mo ago
    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.
    • jasonjmcghee 3mo ago
      I don't personally see people write this message (though I'm sure they do) but dependabot and similar use it. So now I associate it an automated pr vs authored
      • layer8 3mo ago
        I remember HN discussions pre-AI where people staunchly defended the use of that prefix.
        • 3mo ago
• ralferoo 3mo ago
  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's important or it wouldn't be checked in. 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. Even on my solo projects I include a JIRA reference in square brackets before the description. If it's just something I randomly decided to fix during the course of development, I'll create a short 1 line JIRA to get an id and explain the why there.
  • literallyroy 3mo ago
    Is the benefit of using a separate source that you can include images or something else I’m missing? Couldn’t you include context in the commit body?
  • SamuelAdams 3mo ago
    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.
    • pseudalopex 3mo ago
      Commit messages are good release notes rarely.
      • llimllib 3mo ago
        it's usually a "something is better than nothing" situation. If you have somebody willing to write custom release messages, that's definitely better; but conventional commits is better than nothing for it.
• deleted 3mo ago
  [deleted]
• nintenddos 3mo ago
  terrible suggestion, people are awful at writing commit messages and the type is really helpful when you're reviewing history and want to know things at a glance
• estetlinus 3mo ago
  I have never been involved in a project where people make good commits. Having a convention at least forces people to make thoughtful one-liners.
• osigurdson 3mo ago
  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.
  • jeremyjh 3mo ago
    Exactly. People latch onto these perfunctory standards because it’s easier than understanding and clearly communicating the work they’ve done.
    • c-hendricks 3mo ago
      Or they could be used as a stepping stone in teaching people the value of being able to summarize what they've done?
      • jeremyjh 3mo ago
        How does typing “fix:” or “feat:” get you a step closer to being thoughtful?
        • c-hendricks 3mo ago
          To be honest I'm not really sure. I'm also not really sure how tipping "fix:" or "feat:" means people are not understanding their work and performing perfunctory actions though.
          • jeremyjh 3mo ago
            It doesn't force that, but it gives them an out. They can type "fix: frobnicator bug" and think they've written a good commit message because it meets the standard.
• cityofdelusion 3mo ago
  Article is too opinionated IMO. I enforce CC on my projects because I don’t have the energy to police horrendous commit messages. It’s easy to enforce the CC format on the repo merge policy. I do it with the addition of a required issue ID as well. If I only worked with seasoned devs, I wouldn’t use it, but that’s just the reality of my work. It also has a bonus of forcing AI agents to write in the same form as well instead of their random personal flavor. Precommit hooks stop everything before it gets in front of my eyes for review.
  • Merad 3mo ago
    > I enforce CC on my projects because I don’t have the energy to police horrendous commit messages. And does it actually accomplish that goal? I've been on several projects where someone pushed CC on the team with this reasoning. Every time my experience has been that you get the same crappy messages with a tag that may or may not be accurate. BTW, AI absolutely knows how to bypass pre-commit hooks and will do so when they come up with some reasoning why their situation is an exception to the rule. I've watched them do it. The only way I've found to strictly enforce things on an agent (tests, linting, whatever) is to use a claude pre-command hook that will block git commit if the checks don't pass.
• tomjakubowski 3mo ago
  I'm quite fond of vimscript legend Tim Pope's guidance on writing commit messages. https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
• julik 3mo ago
  Previously: https://blog.julik.nl/2020/04/do-not-use-tickets-in-commit-titles https://blog.julik.nl/2020/04/do-not-use-tickets-in-commit-t... with honorable mention of conventional commits. There is nothing conventional about them - it's ceremony that's wasting valuable characters that can have a better use. The article is 100% on the mark.
• jacobsenscott 3mo ago
  There's no benefit to any of this. Just write like human. It will be clear if it's a fix, or a refactor, or ?. Typically it isn't just one of those things.
  • chickensong 3mo ago
    Making an opinionated absolute statement about something that's widely used and argued about isn't even logical. If nobody got any benefit, it wouldn't be a thing. The CC standard may not be for everyone, but having some convention is often helpful. git log --pretty=oneline of structured format gives you broad filtering that's useful. Just writing like a human doesn't give you that ability and you're forced to read every line.
    • procaryote 3mo ago
      Can you give an example of something useful you get from commits following the CC convention?
      • chickensong 3mo ago
        I gave an example right there in my previous comment (log filtering). To expand: our eyes and brains are good at pattern matching. Looking at git log --pretty=oneline with a structure lets you discard any commits irrelevant to what you're looking for without much cognitive effort (e.g. if I'm interested in a code change, I can discard any commit that starts with "docs"). You don't have to read entire lines, only scan the first few characters, or have grep do it for you. Another example is basic metrics stored right there in git. Did changing your testing strategy result in less follow up fixes after feature deployment? You can get that signal with a shell | pipe one-liner. Honestly I'm not die-hard CC convention, but I think it's better than nothing, which is what the person I was responding to was suggesting. If you're using an issue tracker, having a convention to prefix or trailer the commit with the issue ID is the highest value IMHO. The point is having some convention to get teams on the same page and assist with git meta work.
• spit2wind 3mo ago
  So much commit hygiene and fuss appears git induced. Use something other than git and the problems disappear.
• esafak 3mo ago
  The proposal, https://scopedcommits.com/ https://scopedcommits.com/, is not that different. My gripe about conventional commits is the redundancy: fix(ci): fix the foobar
  • johanyc 3mo ago
    I just do: fix(ci): foobar
• animanoir 3mo ago
  [dead]
• hn_throwaway_99 3mo ago
  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 good as anything. 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 tech industry has tons of things that became standards even if they weren't optimal. E.g. if one were starting from scratch I think any sane person would argue JSON should support comments (sorry but Douglas Crawford's rationale for not including comments never made sense to me), better defined numeric formats, etc. But it was better in many contexts than what came before it, so it became the standard. I could believe that there is some other format that differs a bit from conventional commits that is a little better, but not really better enough to want a whole other competing way of structuring comments.
  • olzhasar 3mo ago
    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.
    • bloppe 3mo ago
      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
      • steveklabnik 3mo ago
        Both of these things are discussed in the article. (changelogs and semver)
• dang 3mo ago
  Related. Others? ReleaseJet – Release notes from issue labels, no Conventional Commits - https://news.ycombinator.com/item?id=47847605 https://news.ycombinator.com/item?id=47847605 - April 2026 (1 comment) Why Use Conventional Commits? - https://news.ycombinator.com/item?id=46940152 https://news.ycombinator.com/item?id=46940152 - Feb 2026 (1 comment) Conventional Commits Considered Harmful - https://news.ycombinator.com/item?id=46019218 https://news.ycombinator.com/item?id=46019218 - Nov 2025 (1 comment) Conventional Commits Considered Harmful - https://news.ycombinator.com/item?id=45420887 https://news.ycombinator.com/item?id=45420887 - Sept 2025 (1 comment) Conventional Commits makes me sad - https://news.ycombinator.com/item?id=44482546 https://news.ycombinator.com/item?id=44482546 - July 2025 (2 comments) A specification for adding human/machine readable meaning to commit messages - https://news.ycombinator.com/item?id=40740669 https://news.ycombinator.com/item?id=40740669 - June 2024 (2 comments) A specification for adding human and machine readable meaning to commit messages - https://news.ycombinator.com/item?id=34660646 https://news.ycombinator.com/item?id=34660646 - Feb 2023 (48 comments) Ask HN: Are you still using conventional commits? If not why not? - https://news.ycombinator.com/item?id=33525754 https://news.ycombinator.com/item?id=33525754 - Nov 2022 (4 comments) Conventional Commits - https://news.ycombinator.com/item?id=30950377 https://news.ycombinator.com/item?id=30950377 - April 2022 (1 comment) I Hate Conventional Commits - https://news.ycombinator.com/item?id=29924976 https://news.ycombinator.com/item?id=29924976 - Jan 2022 (1 comment) Conventional Commits - https://news.ycombinator.com/item?id=24208815 https://news.ycombinator.com/item?id=24208815 - Aug 2020 (23 comments) Conventional Commits: A specification for structured commit messages - https://news.ycombinator.com/item?id=21125669 https://news.ycombinator.com/item?id=21125669 - Oct 2019 (95 comments)
• lemonwaterlime 3mo ago
  The issue with all of these schemes is less about the format and more about the semantics itself. What are all the actions that can be done to a codebase and what is a controlled vocabulary that encapsulates those? Then it doesn’t matter what system you use. I spent some time recently coming to the conclusion that I did not prefer CC, but wanting some reliable structure. In the end, I found I was coming up with convoluted schemes that were getting in the way of actually solving my real problems and just settled on the tried and true: “When applied this commit will...” - Add <functionality> - Update <existing> - Refactor <while keeping same boundary behavior> - Remove <some subsystem or functionality> - Cleanup <documentation or style> I don’t consider this to be a complete taxonomy, but it does let me get on with my day and covers most things, especially when combined with thoughtful commit messages.
• ex-aws-dude 3mo ago
  This seems very nitpicky In other words a perfect topic for HN
  • deleted 3mo ago
    [deleted]
• epage 3mo ago
  As a reviewer, I love type first because it sets expectations for what I'm going to look at. Similar if I'm bisecting or doing other history operations. I don't do automated changelogs or versioning but it also makes it faster for me to do so. I really dislike focusing on issue ids. I only want to jump to another tool if I need more information, so put it in the footer for after I've read what is there, like a front page news article giving you the option to go to the back to read more. Worst case that I've seen is people that think the Issue ID is all you need.
• olivierlacan 3mo ago
  Keep a Changelog[0] maintainer here, weirdly seeing this while deep into work on way overdue 2.0 "release"[1], which should be out very soon. I've had to contend with Conventional Commits both in the OSS world and at work as it proliferated from what seemed to me like robotic adoption by folks who were even loosely associated with the Angular ecosystem (remember that?). I've always had a stance with KAC that folks trying to automate changelog creation (prior to LLM rise, mind you) were focusing on the wrong thing. I still think there's a fundamental difference in focus between what you write in a git commit and what you present in a changelog. I know there are fundamental philosophical differences for folks who were used to HISTORY vs. NEWS vs. CHANGELOG but with the growing adoption of KAC-like CHANGELOG.md files and Release Notes (often not synonymous) I think we're thankfully past the weird era were maintainers dumped raw git log ranges between two tags and called that a changelog. I'm sure some still do it. But that's what Conventional Commits tries to replicate. What's really odd to me is that this assumes (broadly) that every single commit in a repository is relevant to the eventual version release changelog (or release notes). Even if you assume some CC types get filtered and deprioritized from generated changelogs by some tools, it's still a huge miss on what communicating about a release typically means: these change likely matter to you as a package dependent or direct user, while others were omitted for good reason. I'm trying to articulate that much more clearly in KAC 2.0 because there's a fundamental paradigm shift when a robot can now analyze recent work (yours or theirs) and craft changelog entries that appropriately shift the audience perspective from "git message for me/us in the future to understand this change" to "changelog entry for you/them to know what this group of changes means". [0]: https://keepachangelog.com https://keepachangelog.com [1]: https://github.com/olivierlacan/keep-a-changelog/pull/600 https://github.com/olivierlacan/keep-a-changelog/pull/600 if anyone's curious and wants to get involved
• murphomatic 3mo ago
  [flagged]
• thom 3mo ago
  Commits should have no information in them. Teams should be aligned on the design of their software, and all the information about that software should be apparent from its source code.
• rawkode 3mo ago
  I have never once considered conventional commits to be about human understanding, but more about automation (release notes, changelogs, and workflows). The commit description and the pull request are for humans.
• mckn1ght 3mo ago
  I like using conventional commits but I’ve often wondered if some sort of tagging/labeling using git-notes wouldn’t be better: https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes I’m just unsure that the short title is the ideal place to put this kind of tagging info: the kind of fix, and optionally, the relevant component(s). I find sometimes that can take up the majority of the title. A forge could consume the git-notes and decorate a commit/pr accordingly. Heck, GitHub PRs already have a labeling system in place, just have to add some glue.
• christophilus 3mo ago
  Yes. It’s just more bike shedding. Write helpful comments if you care about such things. Example: https://www.sqlite.org/src/timeline https://www.sqlite.org/src/timeline
• weinzierl 3mo ago
  I used and use Conventional Commits in private and professional projects and I think they have a place. That being said, when I finally committed to using them something in me broke. Most of my career work was double faced. One face to the customer where you need to keep Tatemae under all circumstances (UI, Tickets, etc.). The other was the code and commit messages where you still kept your professionalism but you could be open and speak the language of your peers. This time is over, maybe for good, but a tiny part of me misses it.
• caraphon 3mo ago
  Why not both? Scope is definitely important. But type is also important: - prioritization: bugfix > docs - visibility: are we spending more time on bug fixes or features? Also, we let AI write the code, are we STILL writing commit messages by hand??
• smrtinsert 3mo ago
  [dead]
• djdeutschebahn 3mo ago
  Thank you for the thorough write up! I just thought about this today and needed the set of arguments and examples you brought forward. Especially the pointers to NixOS et.al. were informative. Thanks!
• tcmart14 3mo ago
  I personally like it for one of my work projects. Its the only one we use it on. Its a repo with the android and iOS app. I like the conventional commits because when doing releases, I can look between two tags and pick out what I need to put in the "What's new in this release" section. I try to not just do the normal, "bug fixes and various improvements," in that section, but what we actually did. Also helping make clear what went into a release branch/what needs to be cherry picked into a release branch. I also don't automate the generation of the "Whats new" section. I just take a look at all the commits between tags. We also tend to do something like bug-ios: <case name> feat-android: <case name> So we don't have generic stuff like bug-ios: fix memory issue
• sennalen 3mo ago
  The best commit message: is what is meaningful to a future you 1 week from now, no further otherwise takes up the least time to think about right now
• wstone 3mo ago
  I totally agree with the sentiment behind this, so much so that I also made my own standard a while ago, https://commits-with-character.org/ https://commits-with-character.org/ an incredibly light addition to the Git Book guidelines, and also gives more priority to scope. It’s been working really well for me in my small projects.
• tantalor 3mo ago
  Old man yells at clouds
  • deleted 3mo ago
    [deleted]
• turadg 3mo ago
  Broken promise 1 (Automatically generating CHANGELOGs) is spot on, especially in a monorepo with multiple released artifacts. A single commit could be a breaking change in one package and refactor in another. But the changelog tools see one commit and include it in both changelogs. Another issue is that once the commit lands on trunk, you can’t revise the entry without editing history. You have to remember to fix it after the changelog is generated. Changesets (https://github.com/changesets/changesets https://github.com/changesets/changesets) is a much better approach. We adopted it in Endo (https://github.com/endojs/endo/tree/master/.changeset https://github.com/endojs/endo/tree/master/.changeset) and it’s been a clear improvement.
• scelerat 3mo ago
  I agree with the sentiments -- knowing the scope of a change is more essential, in most cases, than knowing whether the change was a "fix" or a "feature" -- but much of the scope in a project can be gleaned from the files which were touched. So the use case of, "i need to quickly at a glance determine what commits touched what parts of the project" can be answered with some variation on git log --pretty=format:"%n%h %s" --name-only
• zenoprax 3mo ago
  Inverting the order actually addresses my primary annoyance: what is a feature?! > refactor(core): Update webmcp support to use document.modelContext As the author points out, the line between a fix, an improvement, and general clean-up is blurry and dividing each semantic change into its own commit (and possibly squashed later anyway) is just creating work for no one's benefit. I think Conventional Commits are just an artifact of trying to automate SemVer rather than solving any of the other problems directly. I don't think changelogs should be automated anyway - I can `git log` that if I want a list. A changelog is an opportunity to communicate to a wider audience what is actually going on under the hood.
• cristaloleg 3mo ago
  I prefer how golang/go commits are organized. Simple but working setup.
• bfeynman 3mo ago
  From my own experience in big tech and various OSS things, the crux of this piece rests on this whole scope not being focal point misses that in general the other practice is making sure PRs have limited scope in general so it's marginalized, i.e. reducing blast radius or too big of a change at once by design is implied.
• punkbit 3mo ago
  I stick with Conventional Commits as a standardised way for communicating changes. Most contributions in the form of open PRs are squashed before merging into base branches. A team member can commit as personally wished in the feature branch. I still use CC for my own sanity and I’m very glad I do comparatively to what usually find in others feature branch commit histories. Without standards most developers I’ve seen are very careless. I generally work with changesets to curate changes at the time of contribution in accordance to semantic versioning. What’s great about CC is the simplicity.
• rerdavies 3mo ago
  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?
  • rerdavies 3mo ago
    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".
• NeutralCrane 3mo ago
  This is the kind of thing where the extent to which people get worked up over it far exceeds the benefit of actually doing so. Is it theoretically possible that people can write good commit messages without a framework? Yes. Does that work out in practice across entire teams? No. Any kind of a convention for commit messages is an improvement. Beyond that, type > scope vs scope > type or whatever is splitting hairs. The juice of that debate is not worth the squeeze.
• mianos 3mo ago
  I've been a developer for 40 years. Used VC since rcs. If only people had such pedantry for the actual code, the world would be a better place. I look at the author way more than I read a commit message, next the date and then the code. Never much else.
• hambes 3mo ago
  the article mentions three types of stakeholders: contributors, debuggers and incident responders. it entirely fails to mentions consumers, who mostly care about backwards compatibility of changes, and thus about the type of a change. once the type is established, e.g. a change is breakimg, the consumer next cares about the scope to make downstream adjustments. the part about broken promises regarding breaking changes is _kind of_ fair, but only assuming tooling isn't able to track reverts. accidental breakages occure with every approach and better to have an approximation than no information at all.
• gitscope_ai 3mo ago
  [flagged]
• awill88 3mo ago
  You know what lacks focus? This whole article. Oh, and also individual styles of commit messages. You know what’s a waste of everyone’s time when you’re building technology in 2026? How to write and summarize what you’re work is doing. Conventional commits doesn’t make a promise, it’s a specification. Words have power and meaning, this viewpoint is about more than a spec, it’s about the popularity and relevance that they clearly despise. Conventional commits are like BEM syntax for CSS, it works if you pay attention. It’s structure around what developers do, which thoughtful limits. What is the problem with that? Is it the only way? No. But to say it’s encouraging the “wrong things” pshhhh This author’s take is dog water for coders who yearn to be controversial and (clearly) focus on the wrong things.
• boltzmann64 3mo ago
  Wait. i am already struggling with 50 columns for the title, now i have add this `<type>[scope]:` bloat to it? How are these people doing both "Conventional Commits" and 50-72 at the same time?
• cadamsdotcom 3mo ago
  I feel +/- line counts alone give a good sense of whether something is a fix, a refactor, new feature/component. After that it’s great to know where is primarily intended to be impacted. Then look for what the change is and does. There are some good ideas in this proposal but the author is creating a false dichotomy by saying the current standard should be scrapped. Two things can coexist and both be good. I hope the author reconsiders their approach in their future promotion of their idea.
• matttproud 3mo ago
  Conventional Commit messages have big https://goomics.net/361 https://goomics.net/361 energy. Or at least the mechanisms that repositories use to programmatically enforce their use. (I can't believe nobody has pointed this out yet.)
• ryukoposting 3mo ago
  Conventional commits is one of the weirder cargo-culty things we do in this industry. I do take issue with this, though: > Automatically determining a semantic version bump (based on the types of commits landed): This sounds nice, but the realities of software engineering often interfere significantly with the viability of accurately accomplishing this... imagine a situation where the breaking change you introduced was actually so breaking that you have to revert it... maybe the breakage is subtle and you don’t realise a change is a breaking change when you make the change. Only in retrospect realise that it’s breaking. You will incorrectly increment a minor/patch version when a major version bump is necessary...say you later add a commit which, in composition with a previously breaking commit, results in a diff which is not breaking. Similar to the revert situation, tooling would incorrectly identify a breaking change. This is a problem with Semver, not conventional commits. You're liable to do this regardless of how your commits are formatted, which is one of several reasons why conventional commits are silly. But in this case, Semver itself drew semantic lines that aren't clear, and are easily broken.
• rlpb 3mo ago
  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.
• 839720759 3mo ago
  [dead]