I don't think commit messages are useless at all. It's not about "showing your work" like the author says. It's about summarising the changes in a way that you can quickly read and understand. People forget that commit messages don't have to be just one line, you can write full paragraphs explaining the motivation and thinking behind the change. Many projects enforce detailed commit messages like this because they can be invaluable years down the road when everybody involved is gone.
>Git recently added an --allow-empty-message flag, but really this is backwards. Commit messages should be empty by default. If you want to name your save points, you should have to do so explicitly. Actually, why doesn’t it just constantly autosave your work, like editing text anywhere else (Google Docs, Notion, etc.)?
If I were to clone a repo and find empty commit messages I would probably flip a table and refuse to work on it. This is a terrible idea. How would you use git bisect without commit messages?
The tool should not allow people to do things just because it feels easier.
>We all write them, and they cost the collective engineers of the world countless hours writing ridiculous messages like, “changed something”, “did work”, or the super descriptive, “stuff”.
These kinds of commit messages are typically an indicator of a broken process where somebody needs to commit to see something happen, like a deployment or build process, and aren't able to assert that stuff works locally.
I think the problem comes down to many people just using git as a glorified storage drive for code and not really understanding how to get the most out of the tool.
> These kinds of commit messages are typically an indicator of a broken process where somebody needs to commit to see something happen, like a deployment or build process, and aren't able to assert that stuff works locally.
This is one of my biggest pet peeves with services like github actions. Something running locally like "act" [1] isn't sufficient because it doesn't have everything github has and is extra friction anyway to get everyone to use it for testing.
I think you're missing the point. How a lot of projects operate is that the commits on PR branches are completely pointless since they will be deleted when the PR is merged and the PR description will become the real commit message for the commit on the main branch from the squash-merge.
The trouble is that Git is trying to do two things at once. It's trying to do remote synchronization as well as change tracking all at once.
An alternative is just to do "git commit --amend" every time you want to fix some small bug, but that has downsides in preventing reviewers from seeing what has changed between PR iterations as well as preventing you from going back to an earlier point in time for some branch. When you have less than a dozen commits, it is completely reasonable to just look at diffs and timestamps to determine which commit you want to go back to.
In my opinion, squash merges are evil and enabled only out of necessity because people fill their PRs with spam commits and won't bother to fixup/squash themselves.
There are very good reasons not to enable squash merges. For example, code formatting changes should almost always be in a commit of their own and not squashed together with a refactor or new feature. If you bundle these changes together, git blame output becomes a mess and it's more difficult to distil what the actual changes were in a commit.
Crafting intelligent commits is a skill in itself that more engineers need to learn.
Non-squash commits are kind of a nightmare to actually implement securely. You need to make certain that all the commits are properly assigned to an actual person (no impersonation) which would involve implementing commit signing infrastructure which a lot of orgs don’t want to do.
It can also get confusing as a reviewer if people do any rebasing after submitting the PR.
>Git recently added an --allow-empty-message flag, but really this is backwards. Commit messages should be empty by default. If you want to name your save points, you should have to do so explicitly. Actually, why doesn’t it just constantly autosave your work, like editing text anywhere else (Google Docs, Notion, etc.)?
If I were to clone a repo and find empty commit messages I would probably flip a table and refuse to work on it. This is a terrible idea. How would you use git bisect without commit messages?
The tool should not allow people to do things just because it feels easier.
>We all write them, and they cost the collective engineers of the world countless hours writing ridiculous messages like, “changed something”, “did work”, or the super descriptive, “stuff”.
These kinds of commit messages are typically an indicator of a broken process where somebody needs to commit to see something happen, like a deployment or build process, and aren't able to assert that stuff works locally.
I think the problem comes down to many people just using git as a glorified storage drive for code and not really understanding how to get the most out of the tool.