8 ms·

I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encoun

by bsuvc 6mo ago

I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if developers would actually use it (I hope they will).

sigmoid10 6mo ago
Only two of the five insights are based on commit messages and the author acknowledges that they won't work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.
itmitica 6mo ago
I love how the commentator thinks a developer makes decisions based on commit messages. Random, subjective, or written in a state of mental exhaustion commit messages. I also love the switcheroo the author made: git not logs. But hey :)
8cvor6j844qw_d6 6mo ago
> AI generated commit messages git log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)
mikepurvis 6mo ago
In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.
- bob1029 6mo ago
  And in every codebase I've been in charge of, each PR has one or more issue # linked which describe every possible antagonizing detail behind that work. I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.
  - bikelang 6mo ago
    I personally find this to be a substantially better pattern. That squashed commit also becomes the entire changeset - so from a code archeology perspective it becomes much easier to understand what and why. Especially if you have a team culture that values specific PRs that don’t include unrelated changes. I also find it thoroughly helpful to be able to see the PR discussions since the link is in the commit message.
    - mikepurvis 6mo ago
      I agree, much as it's a loss for git as a distributed system (though I think that ship sailed long ago regardless). As far as unrelated changes, I've been finding that another good LLM use-case. Like hey Claude pull this PR <link> and break it up into three new branches that individually incorporate changes A, B, and C, and will cleanly merge in that order. One minor nuisance that can come up with GitHub in particular when using a short reference like #123 is that that link breaks if the repo is forked or merged into something else. For that reason, I try to give full-url references at least when I'm manually inserting them, and I wish GitHub would do the same. Or perhaps add some hidden metadata to the merge commit saying "hey btw that #123 refers to <https://github.com/fancy-org/omg-project/issues/123 https://github.com/fancy-org/omg-project/issues/123>"
      - bikelang 6mo ago
        Yep - we do exactly the same with Claude. In fact - part of our PR review automation with Claude includes checking whether the PR is tightly scoped or should be split apart. I’d say in about 80% of the cases the Claude review bot is accurate in its assessment to break it up? It’s optional feedback but useful - especially when we get contributors outside our immediate team that maybe don’t know our PR norms and the kinds of things we typically aim for. Yeah I usually default to just a straight up link or a markdown link. Mostly because I usually don’t know the exact number of a PR/ticket/issue - so it’s easy to just copy the URL once I’ve found it.
  - rightofcourse 6mo ago
    It works until you migrate to a new system. In 5 years we are on our 3rd. I saw that at FAANG and startup alike. Then someone might dump the contents in JSON or just PDF for archival but much easier to have the commit msg have the relevant info - only relevant, losts of small details can be still on the issue and if someone really needs them can search those archives.
- tormeh 6mo ago
  I've seen it be the concatenated individual git commit messages way too often. Just a full screen scroll of "my hands are writing letters" and "afkifrj". Still better than if we had those commits individually of course, but dear god. The gold standard is rebased linear unsquashed history with literary commits, but I'll take merged and squashed PR commits with sensible commit messages without complaint.
ramijames 6mo ago
This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.
- PUSH_AX 6mo ago
  I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.
  - freedomben 6mo ago
    It's a stretch to lay at the CTOs feet, but not the team lead or even Head/VP of Engineering IMHO. It's also easy to "enforce" if you're already doing peer review (which you definitely should be, even if not required for compliance).
  - two_tasty 6mo ago
    I partially disagree. Technical leadership at the micro/mid level should be able to set and enforce standards like "you must have semi-meaningful or meaningful commit messages." If and only if they set those standards, and the team does not follow them, then we can say that either the leadership is lacking, or there is a structural barrier/disincentive to following the rules. Within that framework, I do think using process-smells like this is valid for judging technical leadership. To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
  - munksbeer 6mo ago
    I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards. In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc. Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too. I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.
grepsedawk 6mo ago
Only two of the five depend on commit messages. Churn, authorship, and velocity work regardless. Even teams with terrible hygiene write "fix" when something breaks.
- KronisLV 6mo ago
  > Even teams with terrible hygiene write "fix" when something breaks. They might not include anything but the Jira ticket number, if the environment is truly lacking.
- SoftTalker 6mo ago
  As noted, authorship does not if commits are squashed, which seems to be common (I never do it).
heinrichhartman 6mo ago
I personally use git commit -m "." for: "Just snapshots this state real quick" on a feature branch. main branch is advanced on PR level, with squashed commits. So the "." should never make it to main, and have PR description as commit message.
stronglikedan 6mo ago
It's because the vast majority of commit messages are never read by anyone, and there's other ways to fund out what happened in the handful of cases where you would need to.
- scottyah 6mo ago
  git blame's are amazing, and rely on good comments.
- mkehrt 6mo ago
  I read commit messages all the time to figure out what a change was about. For small personal projects I often write one phrase messages with `-m`, but if you're working with other people you should be writing good commit messages.
travisgriggs 6mo ago
Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.
- gcarvalho 6mo ago
  > my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality. e.g. - (a) chore: update some_module to include new_func - (b) feat: Add new_func to handle XYZ case Where: (a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles. (b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language. This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.
lopis 6mo ago
If developers don't write commit messages, that's a culture problem. At my company we demand that of each other.
- hn_throwaway_99 6mo ago
  Totally agree. One thing I really like about HN is it reminds you that nobody's individual experience is indicative of the industry at large. The parent comment stated "Most codebases I encounter just have "changed stuff" or "hope this works now"." I worked at 6 tech companies in my career and a slew of contracting gigs, and I literally never encountered the problem of commit messages being uninformative. Most of the companies developed strict rules for commit comments like always including an issue number (with occasional [NO-ISSUE] tags allowed for minor changes) or something like Conventional Commits, https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ .
yreg 6mo ago
> It's a small minority Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff"). I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.
- brabel 6mo ago
  Never seen that in any company I worked at either and I can’t believe professional developers seem to think that it would be ok to write meaningless commit messages. That’s just so sloppy.
  - parasti 6mo ago
    When your boss looks only at the business output and your most prolific developer writes "save" for commit messages, it gets real hard to enforce a commit message policy. "It's hard to review"? Your boss doesn't care about that and it slows the 10x guy down. These days I just run an LLM on the commits to annotate them (via git notes) based on context.
harryquach 6mo ago
Commit messages are often squashed after merging a feature branch
kelnos 6mo ago
Bad commit messages always fail PR review for me. It requires will and discipline, but it's not that hard.
loremium 6mo ago
tbh I'm not convinced that a git log history should be treated as a group journal because it's not. relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it's just necessary to hit the save button real quick or move a workspace from one device to another. my point is: git is a way of storing and loading files at its core.
max8539 6mo ago
Sometimes it could be just a ticket number/title
- bartvk 6mo ago
  I think that's pretty great, actually. You can look that up to see more info about the commit.
ElijahLynn 6mo ago
And in a squash and merge workflow, which are most teams I've been on the past 8 years, it really is the title of the pull request or merge request. That is what really matters. And I really like that because it leaves room to let the developer do whatever kind of commit messages they want to that makes sense to them. Because nobody's really ever going to read those again after it squashed and merged.
- skinner927 6mo ago
  - fix - fix fr - fix frfr - plz - omg why - never gonna give you up - never gonna let you down - add missing curly braces
- tkzed49 6mo ago
  Every time I hear about commit messages on HN, this is my first thought. I can't imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.
AStrangeMorrow 6mo ago
I also like meaningful commit names. But am sometimes guilty of “hope this works now” commits, but they always follow a first fix that it turns out didn’t cut it. I work on a lot of 2D system, and the only way to debug is often to plot 1000s of results and visually check it behaves as expected. Sometimes I will fix an issue, look at the results, and it seems resolved (was present is say 100 cases) only to realize that actually there are still 5 cases where it is still present. Sure I could amend the last commit, but I actually keep it as a trace of “careful this first version mostly did the job but actually not quite”
aftbit 6mo ago
We have a hard division between "Core" repos (those which are deployed to production / customer sites) and everything else. The expectation in Core repos is that everything goes through a PR process where the pull request message is intended to explain the what and why of the change (perhaps with reference to a ticket, but with the key information restated in the PR), and goes through a review just like the code. Changes are then either squashed with that as the commit message or (if they're larger and benefit from a clear separation of commits), may be rebased with `git rebase -i` assuming the final PR body ends up in one of the commit messages. Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you're not deploying to production. This is excellent for things like test harnesses, CI/CD nonsense, one-off experiments, demos, prototypes, etc. My last Core commit had something like 20 to 1 ratio between lines of commit message to lines of code (small change touching something deep that required a lot of explanation). My last non-Core commit message was "hope this works" (it did not).
renegade-otter 6mo ago
Many organizations squash their commit messages from PR, where most commits actually happen. Unless everyone is committing to trunk all the time, which almost never happens on a real job, I highly doubt the value of this. Showing my Git ignorance here, of course - does "ancestors(trunk)" pull in all the commit messages?
alper 6mo ago
> developers write commit messages The people who don't write commit messages for us are the non developers. Writing commit messages shouldn't take any time at all. If it does, then you probably have a range of other professional issues.
HeinrichAQS 6mo ago
One big problem about commit messages is, that you write them from your perspective. If you write them while activly engaged with the topic and changes you are very heavily biased and might miss things which are obvious to you but not to future readers with less knowledge. I think abstracting your personal opinion is quite hard - I agree that LLMs are perfectly fitting for writing this since they just dont have a "personal opinion". Atleast I made the mistake in the past many times focusing on the things which were not obvious to me but then leaving out the non obvious things for others.
zimpenfish 6mo ago
> Most codebases I encounter just have "changed stuff" or "hope this works now". I have been told off several times at different jobs for writing commit messages that are "too big". Also for writing too much commentary in my code changes. Also also for complaining that other people aren't doing these things. (Not that it stops me, mind, but it does make working relationships fractious.)
smallpipe 6mo ago
I do not approve PRs from junior devs until the commit message is useful.
mystickphoenix 6mo ago
Likely my own personal bias, but I have never once found git log/commit messages to be useful when debugging or understanding what happened. I'm sure that others do so I try to write useful commits (conventional commits syntax is helpful here) but I'd much rather spend my time and effort understanding the current state of the codebase instead of trying to diagnose how "fixed bug related to file naming" relates to a website going down.

by bsuvc 6mo ago

sigmoid10 6mo ago

Only two of the five insights are based on commit messages and the author acknowledges that they won't work in projects without message discipline. But the remaining ones will give you valuable insights even into the most lazy project department.

itmitica 6mo ago

I love how the commentator thinks a developer makes decisions based on commit messages. Random, subjective, or written in a state of mental exhaustion commit messages. I also love the switcheroo the author made: git not logs. But hey :)

8cvor6j844qw_d6 6mo ago

> AI generated commit messages git log --oneline and a sprinkle of your personal sauce on .claude goes a long way :)

mikepurvis 6mo ago

In codebases where PRs are squashed on merge, the commit messages on the main branch end up being the PR body description text, and that's actually reviewed so tends to be much better I find.

bob1029 6mo ago
And in every codebase I've been in charge of, each PR has one or more issue # linked which describe every possible antagonizing detail behind that work. I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.
- bikelang 6mo ago
  I personally find this to be a substantially better pattern. That squashed commit also becomes the entire changeset - so from a code archeology perspective it becomes much easier to understand what and why. Especially if you have a team culture that values specific PRs that don’t include unrelated changes. I also find it thoroughly helpful to be able to see the PR discussions since the link is in the commit message.
  - mikepurvis 6mo ago
    I agree, much as it's a loss for git as a distributed system (though I think that ship sailed long ago regardless). As far as unrelated changes, I've been finding that another good LLM use-case. Like hey Claude pull this PR <link> and break it up into three new branches that individually incorporate changes A, B, and C, and will cleanly merge in that order. One minor nuisance that can come up with GitHub in particular when using a short reference like #123 is that that link breaks if the repo is forked or merged into something else. For that reason, I try to give full-url references at least when I'm manually inserting them, and I wish GitHub would do the same. Or perhaps add some hidden metadata to the merge commit saying "hey btw that #123 refers to <https://github.com/fancy-org/omg-project/issues/123 https://github.com/fancy-org/omg-project/issues/123>"
    - bikelang 6mo ago
      Yep - we do exactly the same with Claude. In fact - part of our PR review automation with Claude includes checking whether the PR is tightly scoped or should be split apart. I’d say in about 80% of the cases the Claude review bot is accurate in its assessment to break it up? It’s optional feedback but useful - especially when we get contributors outside our immediate team that maybe don’t know our PR norms and the kinds of things we typically aim for. Yeah I usually default to just a straight up link or a markdown link. Mostly because I usually don’t know the exact number of a PR/ticket/issue - so it’s easy to just copy the URL once I’ve found it.
- rightofcourse 6mo ago
  It works until you migrate to a new system. In 5 years we are on our 3rd. I saw that at FAANG and startup alike. Then someone might dump the contents in JSON or just PDF for archival but much easier to have the commit msg have the relevant info - only relevant, losts of small details can be still on the issue and if someone really needs them can search those archives.
tormeh 6mo ago
I've seen it be the concatenated individual git commit messages way too often. Just a full screen scroll of "my hands are writing letters" and "afkifrj". Still better than if we had those commits individually of course, but dear god. The gold standard is rebased linear unsquashed history with literary commits, but I'll take merged and squashed PR commits with sensible commit messages without complaint.

ramijames 6mo ago

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

PUSH_AX 6mo ago
I think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.
- freedomben 6mo ago
  It's a stretch to lay at the CTOs feet, but not the team lead or even Head/VP of Engineering IMHO. It's also easy to "enforce" if you're already doing peer review (which you definitely should be, even if not required for compliance).
- two_tasty 6mo ago
  I partially disagree. Technical leadership at the micro/mid level should be able to set and enforce standards like "you must have semi-meaningful or meaningful commit messages." If and only if they set those standards, and the team does not follow them, then we can say that either the leadership is lacking, or there is a structural barrier/disincentive to following the rules. Within that framework, I do think using process-smells like this is valid for judging technical leadership. To the point of other commenters however, I wouldn't lay something this micro at the foot of the CTO in all but the smallest of organizations.
- munksbeer 6mo ago
  I don't agree. These things actually matter. A developer who isn't told otherwise is just going to do whatever they feel like, so if there is nothing or no-one enforcing the standards, then the failure isn't on the individual developer, it is on the team lead. Someone needs to be setting the standards. In the company I work for, there is a team that has isolated itself to some extent from other teams and works at a furious pace to keep their particular section of the business happy. We're lucky enough that they spun up their own repo to do their work on, so they don't actually impact other teams, but if the quality of the commit messages is anything to go by, I am 100% certain they're going to end up in a huge mess, if they aren't already. The team lead encourages this, and certainly doesn't care about commit messages etc. Developers who care about other developers tend to write better quality code, because they care what other developers think of them. If you care about other developers, you will most likely write decent quality commit messages too. I have seen over many years the types of developers who only care about moving their own code into production as fast as possible and getting to the next thing. There is a very high correlation with a mess at the end, which they inevitably won't have to tidy up because they'll be doing the next thing. These types of developers hate owning stuff in production, so they don't do it, so they don't actually care how maintainable their "clever" code is. I am very certain that a number of people reading this will be those types of developers.

grepsedawk 6mo ago

Only two of the five depend on commit messages. Churn, authorship, and velocity work regardless. Even teams with terrible hygiene write "fix" when something breaks.

KronisLV 6mo ago
> Even teams with terrible hygiene write "fix" when something breaks. They might not include anything but the Jira ticket number, if the environment is truly lacking.
SoftTalker 6mo ago
As noted, authorship does not if commits are squashed, which seems to be common (I never do it).

heinrichhartman 6mo ago

I personally use git commit -m "." for: "Just snapshots this state real quick" on a feature branch. main branch is advanced on PR level, with squashed commits. So the "." should never make it to main, and have PR description as commit message.

stronglikedan 6mo ago

It's because the vast majority of commit messages are never read by anyone, and there's other ways to fund out what happened in the handful of cases where you would need to.

scottyah 6mo ago
git blame's are amazing, and rely on good comments.
mkehrt 6mo ago
I read commit messages all the time to figure out what a change was about. For small personal projects I often write one phrase messages with `-m`, but if you're working with other people you should be writing good commit messages.

travisgriggs 6mo ago

Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.

gcarvalho 6mo ago
> my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality. e.g. - (a) chore: update some_module to include new_func - (b) feat: Add new_func to handle XYZ case Where: (a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles. (b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language. This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.

lopis 6mo ago

If developers don't write commit messages, that's a culture problem. At my company we demand that of each other.

hn_throwaway_99 6mo ago
Totally agree. One thing I really like about HN is it reminds you that nobody's individual experience is indicative of the industry at large. The parent comment stated "Most codebases I encounter just have "changed stuff" or "hope this works now"." I worked at 6 tech companies in my career and a slew of contracting gigs, and I literally never encountered the problem of commit messages being uninformative. Most of the companies developed strict rules for commit comments like always including an issue number (with occasional [NO-ISSUE] tags allowed for minor changes) or something like Conventional Commits, https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ .

yreg 6mo ago

> It's a small minority Is it really a small minority? I have never worked on a project that didn't have commit messages that at least tried to be descriptive (sometimes people fail at it but its very different to an outright "changed stuff"). I don't remember any friend mentioning to me them encountering a work project where the messages were totally neglected either.

brabel 6mo ago
Never seen that in any company I worked at either and I can’t believe professional developers seem to think that it would be ok to write meaningless commit messages. That’s just so sloppy.
- parasti 6mo ago
  When your boss looks only at the business output and your most prolific developer writes "save" for commit messages, it gets real hard to enforce a commit message policy. "It's hard to review"? Your boss doesn't care about that and it slows the 10x guy down. These days I just run an LLM on the commits to annotate them (via git notes) based on context.

harryquach 6mo ago

Commit messages are often squashed after merging a feature branch

kelnos 6mo ago

Bad commit messages always fail PR review for me. It requires will and discipline, but it's not that hard.

loremium 6mo ago

tbh I'm not convinced that a git log history should be treated as a group journal because it's not. relying on git commit messages assumes they're correct by convention since there is no technical constraint to enforce it. and it assumes no work in progress commits, sometimes it's just necessary to hit the save button real quick or move a workspace from one device to another. my point is: git is a way of storing and loading files at its core.

max8539 6mo ago

Sometimes it could be just a ticket number/title

bartvk 6mo ago
I think that's pretty great, actually. You can look that up to see more info about the commit.

ElijahLynn 6mo ago

And in a squash and merge workflow, which are most teams I've been on the past 8 years, it really is the title of the pull request or merge request. That is what really matters. And I really like that because it leaves room to let the developer do whatever kind of commit messages they want to that makes sense to them. Because nobody's really ever going to read those again after it squashed and merged.

skinner927 6mo ago
- fix - fix fr - fix frfr - plz - omg why - never gonna give you up - never gonna let you down - add missing curly braces
tkzed49 6mo ago
Every time I hear about commit messages on HN, this is my first thought. I can't imagine not working in a squash workflow. No matter how good your commit messages are, I do not want to read all of them. The squashed commit will direct me to the original PR in case I need more detail.

AStrangeMorrow 6mo ago

I also like meaningful commit names. But am sometimes guilty of “hope this works now” commits, but they always follow a first fix that it turns out didn’t cut it. I work on a lot of 2D system, and the only way to debug is often to plot 1000s of results and visually check it behaves as expected. Sometimes I will fix an issue, look at the results, and it seems resolved (was present is say 100 cases) only to realize that actually there are still 5 cases where it is still present. Sure I could amend the last commit, but I actually keep it as a trace of “careful this first version mostly did the job but actually not quite”

aftbit 6mo ago

We have a hard division between "Core" repos (those which are deployed to production / customer sites) and everything else. The expectation in Core repos is that everything goes through a PR process where the pull request message is intended to explain the what and why of the change (perhaps with reference to a ticket, but with the key information restated in the PR), and goes through a review just like the code. Changes are then either squashed with that as the commit message or (if they're larger and benefit from a clear separation of commits), may be rebased with `git rebase -i` assuming the final PR body ends up in one of the commit messages. Non-Core repos are absolute free-form anything goes. You can commit 8 times a day without a PR as long as you're not deploying to production. This is excellent for things like test harnesses, CI/CD nonsense, one-off experiments, demos, prototypes, etc. My last Core commit had something like 20 to 1 ratio between lines of commit message to lines of code (small change touching something deep that required a lot of explanation). My last non-Core commit message was "hope this works" (it did not).

renegade-otter 6mo ago

Many organizations squash their commit messages from PR, where most commits actually happen. Unless everyone is committing to trunk all the time, which almost never happens on a real job, I highly doubt the value of this. Showing my Git ignorance here, of course - does "ancestors(trunk)" pull in all the commit messages?

alper 6mo ago

> developers write commit messages The people who don't write commit messages for us are the non developers. Writing commit messages shouldn't take any time at all. If it does, then you probably have a range of other professional issues.

HeinrichAQS 6mo ago

One big problem about commit messages is, that you write them from your perspective. If you write them while activly engaged with the topic and changes you are very heavily biased and might miss things which are obvious to you but not to future readers with less knowledge. I think abstracting your personal opinion is quite hard - I agree that LLMs are perfectly fitting for writing this since they just dont have a "personal opinion". Atleast I made the mistake in the past many times focusing on the things which were not obvious to me but then leaving out the non obvious things for others.

zimpenfish 6mo ago

> Most codebases I encounter just have "changed stuff" or "hope this works now". I have been told off several times at different jobs for writing commit messages that are "too big". Also for writing too much commentary in my code changes. Also also for complaining that other people aren't doing these things. (Not that it stops me, mind, but it does make working relationships fractious.)

smallpipe 6mo ago

I do not approve PRs from junior devs until the commit message is useful.

mystickphoenix 6mo ago

Likely my own personal bias, but I have never once found git log/commit messages to be useful when debugging or understanding what happened. I'm sure that others do so I try to write useful commits (conventional commits syntax is helpful here) but I'd much rather spend my time and effort understanding the current state of the codebase instead of trying to diagnose how "fixed bug related to file naming" relates to a website going down.