I think it is a good idea to have commits on a rather fine granularity,
such that each commit represents one independent feature, bug fix, or
refactoring. A feature can be much smaller than a user-visible feature,
for example, just a small enhancement or new function; it may also be a
set of new tests.
The key is not to mix different things in one commit. SVN does not
support this well, because one cannot commit code off-line. git (or hg)
allow off-line commits, making it much easier to keep up a "discipline"
of frequent, small, independent commits.
As Pavel said, this makes it much easier to find regression problems;
git (and hg) even support this with a special command (git bisect).
FWIW, a few years ago I studied several large open source projects using
CVS or SVN. They all suffered from some long-standing regression bugs
that could not be fixed, sometimes even after years. One of the reasons
why is that the commit in question was hundreds or thousands of lines,
sometimes because the developer was off-line for some time before being
able to commit code. Hence, off-line commits using git or hg are
extremely helpful, because they can prevent this problem.
there is actually something on this.
its good idea that having some "final" tree where 1 feature=1
commit. its blessing when you dig out something in history. it would
spare amounts of my time when bisecting history to find regression
culprits.
on the other i find the above "beats" important for life of the
community around dev list, so whatever dev model we adopt some
git-commit mailing list where things go imeddiately not waiting for
some final merged or approval feature-commit is must-have imho.
--
Regards,
Cyrille Artho - http://artho.com/
If you can, help others. If you can't, at least don't hurt others.
-- the Dalai Lama
