4 ms·

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

by tux3 2y ago

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.

saagarjha 2y ago
Address structural issue with code contributions In some cases, it's possible to end up with commit messages that carry very little value. Unfortunately, while the minimum is clearly insufficient, it is possible to "expand" the minimum into a specific format without substantially improving the quality of the commit message. For example, a substantial refactor can easily just be described as a list of the changes that it included, rather than a rationale for why it was done (which is not readily apparent from the change itself). In the long run, problems involving people can be improved by process, but cannot wholly be solved by them. Pernicious failures need to be acted upon directly. Demonstrating the value of good commit messages is often a better driver of improvements than a template that is a chore to fill out.
MrJohz 2y ago
In my experience, people write overly short commit messages when they're writing too many commit messages. The solution is usually not to teach people to write better commit messages (although that's also good), but to teach them how to group and bundle commits together to create a meaningful standalone patch. One of the easiest ways to start there is to adopt PR-based review systems, where any number of commits can get pushed to a git repository and then reviewed as a single block. This is fairly inflexible, but it is very simple to get started with (no need to learn any special rebasing commands, just add, commit, add, commit, push). Most git forges allow you to do squash merges, so everything in the PR will become a single commit, usually with the PR description as a commit message. Then you can refine the commit and commit message during the review process. There are better tools out there, but in my experience, this is the quickest way to get started for most teams, especially as you're probably already using a forge that allows you to do all of this already.

by tux3 2y ago

saagarjha 2y ago

Address structural issue with code contributions In some cases, it's possible to end up with commit messages that carry very little value. Unfortunately, while the minimum is clearly insufficient, it is possible to "expand" the minimum into a specific format without substantially improving the quality of the commit message. For example, a substantial refactor can easily just be described as a list of the changes that it included, rather than a rationale for why it was done (which is not readily apparent from the change itself). In the long run, problems involving people can be improved by process, but cannot wholly be solved by them. Pernicious failures need to be acted upon directly. Demonstrating the value of good commit messages is often a better driver of improvements than a template that is a chore to fill out.

MrJohz 2y ago

In my experience, people write overly short commit messages when they're writing too many commit messages. The solution is usually not to teach people to write better commit messages (although that's also good), but to teach them how to group and bundle commits together to create a meaningful standalone patch. One of the easiest ways to start there is to adopt PR-based review systems, where any number of commits can get pushed to a git repository and then reviewed as a single block. This is fairly inflexible, but it is very simple to get started with (no need to learn any special rebasing commands, just add, commit, add, commit, push). Most git forges allow you to do squash merges, so everything in the PR will become a single commit, usually with the PR description as a commit message. Then you can refine the commit and commit message during the review process. There are better tools out there, but in my experience, this is the quickest way to get started for most teams, especially as you're probably already using a forge that allows you to do all of this already.