This question already has an answer here:
A discussion has come up at work and I want to get the opinion of other programmers.
During my time in college, we only used SVN for sourcecontrol. Everybody commits to the same server and all changes are pulled to all machines. In this system, it's easy when you should push your changes: when you're done with your changes. However, this makes merging changesets by multiple developers a complete nightmare.
However, for the past year or so that I've been programming professionally, we've been using Mercurial for source control. At first, I was using it like SVN: work on a featur, commit and push in one go, but only when it's finished.
Gradually, my habits started to change. I learned about branches, how commits could be a draft, public or secret and even used a USB stick as a central repository. My commits became smaller, but they increased in quantity. Instead of committing and pushing in one go, I would make commits for every change in a named branch.
Here's what the repository for one my personal projects looks like:
I see a couple of advantages in this approach.
Small commits mean they are focused on a single subject. Every commit gets a one-line description of the changes, which makes them easy to follow even after weeks of inactivity.
Named branches keep you on topic. If you're working in the "refactor-text-rendering" branch, for example, you shouldn't make changes to the math library, because that's not related to the branch's topic.
However, the lead developer is annoyed by my methodology. He feels that the small commits clutter up the repository's history. His preferred methodology is to work in a patch. When the feature is done, he merges the commits and pushes them in one go.
So, what do you prefer? A flow of consciousness history of commits or a patch of changes every now and then? Or something else entirely?