Can commits be considered too small? [duplicate]

Question

Possible Duplicates:
git / other VCS - how often to commit?
How often should I/do you make commits?

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).

Examples

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.

  by:

  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.

Questions

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?

Answer 1

Wrong is too strong a word, because this is a matter of style/preference. However, my preference is apparently diametrically opposed to yours.

I much prefer seeing coding style edits and small documentation changes done in their own commits. If I'm doing a code review, or trying to figure out where a bug was introduced, it's much easier if each commit doesn't touch on half a dozen random issues. In my world an ideal commit fixes one bug, or completes one feature. That way if the fix or new feature turns out to have some serious problem, backing it out is much easier: you don't have to try and untangle a grab-bag of changes unrelated to the problem.

Now, if you have a batch of changes that are documentation/formatting issues only, feel free to bundle those together, and your commit comment should indicate "Formatting/documentation changes only".

Answer 2

First of all, I don't think there is one answer to this question. As you point out, it differs a lot between individuals and projects.

I apply something like the idea of SoC (Separation of Concerns) to commits. That is, I try to commit on a "per task" basis. Or, in other words, avoid committing "several areas of work" at once. In that sense, there is no such thing as a commit too small.

Answer 3

Small commits are great. IMHO, the smaller the better. In particular, small commits are good because they are easily reviewable. I would rather review 5 small independent changes than 1 larger change that incorporates them all.

Answer 4

I don't think any commit could be too small as long as the comment is accurate; lack of or misleading commit comments are reprehensible.

Personally I prefer to commit changes in logical groups, e.g. one commit for refactoring before making any logical changes, then another for changes to fix the bug.

I also prefer comments to contain some detail, so I'll look through all files that have changed in order to gather related changes that can be covered by the same comment, separating those that need some detail that doesn't apply to other files.