No subject

Every revision should be a transformation moving the project from one valid state to another valid state, validity obviously including not breaking the build and much more than that.

Technically, this property is invaluable with tools like bisect. But it has implications on the development process itself: if the project is broken then it is a bug. It is not "Oh my, I pushed while I was in a middle of a refactoring, sorry" or something. And even more important, *if forces developers to think about their features in term of successive, meaningful and minimal, working transformations*. I am convinced doing that made me write better code, in a better way. And I am convinced it helps controlling the risks: breaking changes will usually require larger commits than innocuous ones, and larger commits are harder to review.

Conclusion: breaking changes are easier to detect and since they require more attention at review time you will probably have peer pressure to avoid them and force people to think of better way to achieve the same result. 

Here, using quick commits would hide the risks brought by the global changes.

--
Patrick Mézard