The usage of source control is very different from one developer to another and from project to another. Some commit very often; others can spend a whole day or several days without committing (especially when they work on the project alone or they know that other team members are working on very different part of the project).
Sometimes, I've seen extremely small commits, both in real life and in webcasts and other learning material. Some examples, mostly from real life, are:
A commit which solves a bug #... or implements a feature #... by changing one line of code.
IMHO, it's a perfectly valid case for a commit, especially if the bug tracking system is linked to the version control and is updated automatically according to the revisions. Even without this link, it's useful to track which commit solved what, independently of the number of changes required to solve a bug or implement a feature.
A commit which changes a single configuration setting (given that in the context, configuration settings must be in source control).
IMHO, this could be merged sometimes with another commit, unless the previous setting breaks the build or introduces a bug or can affect other developers (for example a connection string which changed after the test database server was migrated).
A commit which corrects spelling of a word, for example in a string displayed to the user.
IMHO, in most cases, this can be merged with another commit (unless, again, it breaks the build). The only case where it cannot be merged is when, if left, the wrong spelling can be propagated through code and would be too complicated or impossible to change later, as with HTTP referer header.
A commit which adds a comment to a method (while the method was already explicit enough) or solves another minor style-related rule.
Example: in .NET Framework, StyleCop requires to document every method, and the XMLDoc comment for a constructor (which is method too) must begin with:
Initializes a new instance of the <Class name here> class.
A commit can enforce this last rule, replacing a comment in legacy code:
Creates a new vehicle with the specified number of wheels.
Initializes a new instance of the Vehicle class, using the specified number of wheels.
In other words, the revision has no meaning other than to conform the piece of code to the style standards used in the codebase.
IMHO, this can be merged with another commit in every case (after all, style-related rules must be enforced at commits to reject the commits of the code which doesn't match them), unless there are several changes in several places.
Am I wrong on those points?
Is there such a thing as a commit too small, or is a practice of committing very often a best practice?
Does it worth it to commit too small changes, given that it would "pollute" the revision log and make it more difficult to find the relevant changes among tiny changes nobody cares about and which don't break or unbreak the build, nor affect other developers?