Don't commit half-ready implementation. It will (at least one of this)

* break the build 
* break the (busines) logic
* cause bugs
* obfuscate team members.  ''(Dude, who performed a mid-task integration?  Now George is all obfuscated; call the manager, we're going to need to refactor George before continuing.)  (Sorry, I couldn't resist.)''

----

I will do exactly this. Rember, SeparatePolicyAndMechanism. I will often checkin the mechanism early with a policy that is do not apply mechanism in any case.

''So your principle is to apply anti-YagNi?  You check it in even when it can be demonstrated that you don't need it?''

----

This is highly dependent on your VersionManagement software.  It is very helpful to have a system that can commit changes, but not apply them to the mainline build (yet).  This gives a good rollback point to base further work on, without disturbing other developers.  

For example, with git, you can commit many times to a private branch your local repository, and push your changes to the lead developer only when they are ready for integration.  See ExtremeVersionControl.