I gave a skim and didn't find this
11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code doesn't build.)
11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code doesn't build.)
If your commit is broken, it's not meaningful, it's just broken.
> If you wait until everything works you'll end with huge meaningless conflicting commits.
Reading comprehension, please. b0sk talked about commits which can not be built. It's a very clear and simple requirement and it definitely does not mean is not feature-complete.
> Of course it is quite annoying if you use a centralized SCM since everything you commit becomes public. Well this is actually why you should not use centralized SCM.
There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable.
> If your commit is broken, it's not meaningful, it's just broken.
Sometimes I make broken commits just to have something for the written record. Sometimes I rebase them away. Sometimes I ask friends to pull from a broken commit (gasp!) when I need their help to fix my bug. Often times I 'git commit --amend' to fix broken commits before I push. In any case, there's no reason to artificially hide these mistakes as long as the result works.
> There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable.
Git allows you to automatically skip untestable commits. See http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h...
In my workflow, I usually use a 'master' branch and 'topic' branches. The master must always build, as you say. Topic branches don't -- they're experimental by definition. When a topic is ready to go, we rebase and clean up the commits. This way, we get a traceable, ever-buildable source tree from master and experimental branches when we want them.
Problem?
With DVCS you can create your own branch and push it to other systems super easily, so there's little excuse for checking in broken code to a shared branch. Also, with a lot of newer VCSes there's often a feature to "shelve" a changeset to a central DB without committing it.
Not to mention that breaking the build for more than a few minutes raises some serious red flags about the way you're working.
But there are a few cases where it's a necessary evil. For example, when upgrading a large Rails application from Rails 2.3 to 3.0, you're likely to make hundreds of small changes before everything works again.
In this case, I create a new branch, prepend "BROKEN:" to each commit message, and record the number of unit tests that are currently passing. Once all the tests are fixed, I hand-test, add new tests for any regressions that weren't caught by the automatic tests, and merge back to the main development branch.
Only if no one else ever saw that part of history, right?
:: shaky eyes ::
There's always repercussions to checking in unbuildable code. Suddenly, nobody else can contribute or pull from that branch without first fixing your bad code, for one. What's worse is when they think it's a mistake and do tweak your code. You'll have to backtrack then, adding noise to the file's history. Another is when you need to roll back. If you allow broken commits, there's always a change of hitting a broken version. In times of emergency, you really don’t want to be bogged down by unbuildable code.
That's what branches are for. That's the whole point of committing often.
A disciplined approach to branching will deal with the problem.