Hacker News new | ask | show | jobs
by tux3 450 days 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.
2 comments
saagarjha 450 days 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.
link
MrJohz 450 days 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.

link