I absolutely agree that you should commit early and often, and that short one-liners for those commits are fine. It is when you go to merge that you need to hav

I absolutely agree that you should commit early and often, and that short one-liners for those commits are fine. It is when you go to merge that you need to have good messages and there are several ways you can do that, depending on your team's preferences: * You can rebase and groom your commits into meaningful sets of changes each with good descriptions (how Linux uses git). * You can squash all the commits, and always just have a single commit for each merge with a detailed description. * You can keep your full commit history as a record of how the work was actually done (Fossil encourages this philosophy), but always have a detailed merge commit that can stand-alone in describing all the work done in that merge.