I think the article put the finger of something important. I have had the fortune to work at a few places where developers treat their RCS not only as the repo

I think the article put the finger of something important. I have had the fortune to work at a few places where developers treat their RCS not only as the repo, but as a tool for communication. And the efficiency of collaboration is truly impressive. As an example I developed a new memory sub system for an embedded CPU (ASIC) and as soon as I committed the new version (and stating so in the commit message), the dev doing verification checked out the design and ran his test suite on it. (And yes, I had run my own tests before committing.) But comminicating through the RCS hinges on having good ways of observing changes to the repo (post-commit mails etc) - and providing proper commit information. The first example in the article looks somewhat verbose for my taste. But it states the what the commit contains, what it solves, any caveats. Very good. When I commit a transaction that contains several related changes I usually use something like (1) ABC, (2) XYX... The only exception to good commit messages at one of the companies I talked about was one dev that always used one of three messages: "little change", "big change", "major change". Very helpful...