Let's try this again. Speaking as a git user, my workflow is a little different. > If your commit is broken, it's not meaningful, it's just broken. Sometimes

Let's try this again. Speaking as a git user, my workflow is a little different. > 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.html#_bisect_run 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?