“WIP”
The Lost Art of Commit Messages
31–40 of 61 posts
Re: The Lost Art of Commit Messages
#32This is one of the cases where I think AI can help.
Two usecases I can think of: non-native English speakers and ADHD developers. For those groups, having some tool that autofills the first draft of the commit message (that you can then modify) would probably improve their overall commit message quality.
A quick google gave me several projects:
- https://github.com/Nutlope/aicommits
- https://github.com/insulineru/ai-commit
I'm sure there's more.
Re: The Lost Art of Commit Messages
#33Reject commit message suggestions When working on large software projects, commit messages that follow the format suggested by the author rarely provide additional value. Having commits prefixed by "chore:" or "docs(ui):" aren't that useful. Instead, some of those 50 characters can be used for more descriptive titles. Commit messages are often the best and only context available when bisecting a bug, so bullet points…
The author is working in an environment where, left to their own device and allowed free form messages, programmers write the three word sentences shown in the blog post.
This is the downside of the variation in style across contributors. It works if people want to build something, and not just do the minimum. Open source projects frequently have no such limitations.
But I am sad to report that some people appear to need the structure.
Re: The Lost Art of Commit Messages
#34Reject commit message suggestions When working on large software projects, commit messages that follow the format suggested by the author rarely provide additional value. Having commits prefixed by "chore:" or "docs(ui):" aren't that useful. Instead, some of those 50 characters can be used for more descriptive titles. Commit messages are often the best and only context available when bisecting a bug, so bullet points…
> Having commits prefixed by "chore:" or "docs(ui):" aren't that useful.
I don't use those for humans, I use those for tooling, such as semantic-release. The human-readable bits come after that.
Re: The Lost Art of Commit Messages
#35A dev culture that produces nothing but wip and fix bug commits (frequently adding unrelated refactors) will continue to produce noise but prefixed with chore(code): fix bug. I fail to see the benefit behind this and conventional commits.
I do not understand why people insist on trowing inane technical solutions at social problems. It doesn't work.
Re: The Lost Art of Commit Messages
#36Depends. Sometimes a one-liner or a reference to a ticket is enough. There are times when I make a one-line change and write a paragraph or two explaining why it had to be done. But these kinds of things often drown in the noise of a dozen other changes. If that one was important enough, I will reference it in an ongoing discussion or documentation, or at least include "read below:" on the first line. I usually see p…
If I feel the need to write a paragraph in a commit message it's usually a sign that Im writing prose that belongs in actual docs.
Commit messages are a great place to bury docs nobody will look at.
Re: The Lost Art of Commit Messages
#37Reject commit message suggestions When working on large software projects, commit messages that follow the format suggested by the author rarely provide additional value. Having commits prefixed by "chore:" or "docs(ui):" aren't that useful. Instead, some of those 50 characters can be used for more descriptive titles. Commit messages are often the best and only context available when bisecting a bug, so bullet points…
> Having commits prefixed by "chore:" or "docs(ui):" aren't that useful. I don't use those for humans, I use those for tooling, such as semantic-release. The human-readable bits come after that. https://semantic-release.gitbook.io/
I always thought we have tags for tooling.
Re: The Lost Art of Commit Messages
#38This focuses on the format of the git message, but I would argue what matters more is the content.
The most important thing to convey in a git commit message is the why, not the what or how.
The title should be a short summary of the change (the what), so that it can easily be searched for.
The description should explain why this change needed to be made. The how and the what can be determined by reading the code. But more often than not, explaining the why helps to clarify intent so that future readers can determine if your rationale still holds.
Re: The Lost Art of Commit Messages
#39Depends. Sometimes a one-liner or a reference to a ticket is enough. There are times when I make a one-line change and write a paragraph or two explaining why it had to be done. But these kinds of things often drown in the noise of a dozen other changes. If that one was important enough, I will reference it in an ongoing discussion or documentation, or at least include "read below:" on the first line. I usually see p…
A one-liner: sure. A ticket? No; ticket systems are transient and not always available. You shouldn't need to open an external system that may no longer exist in 20 years time (for example) to get the full context. Compare the Linux commit history, every commit has its full context and explanation and they do not rely on external systems.
20? Try 5...
I"m working on a repository that uses at least four different jira ticket number formats. All commits should have a jira reference but I think only the current format can still be looked up. And maybe the predecessor if you know what jira field to query. All the rest are lost in corporate limbo. Not that those tickets added much more context to the actual commit...
So yeah, always write your commit messages as standalone as possible.
Re: The Lost Art of Commit Messages
#40These example commits seem like pretty bad commit messages to me. They are just a summery of the changes (something a motivated reader can rediscover by reading the diff), while leaving out the why, which will be lost to history if not documented.
Yes, the why is very very important, but imo it's also useful with a one-liner summary of the actual change.
Consider a trivial change but affecting tens of places in the code, eg an API change. It's very useful to be able to quickly glance past "use new abc-API; required since dependency X bumped to Y" and mentally move on, rather than actually having eyes scanning over those actual changes.