Strategies for push/merge problem?

[Benjamin Smedberg]

Adrian Buehlmann wrote:

> But I wonder if a project e.g. like Mercurial would accept a changeset
> like this:
> 
> "This is what I achieved until 5pm. Currently, the testsuite is
> broken, but if I manually set variable x to an illegal value z, I
> can almost do feature X. I will continue tomorrow morning, but I had
> to commit this state in order to being able to take it home on my
> USB stick RIGHT NOW (need to run!)".
> 
> Who wants to see such a changeset in the eternal history of any non-toy,
> non-hobby, non-single-developer, non-throw-away project?

Contra-example:

In Mozilla we are working on some very large automatic refactoring projects. 
I am currently maintaining these projects as a patch queue, but when it 
comes time to push them finally, I will be pushing something like this:

A - manual rewrite of class X, reviewed by Joe
B - manual rewrite of class Y, reviewed by Amy
C... about 120 patches
X - automatically rewrite removing stack nsCOMPtrs
Y - automatically rewrite class hierarchy
Z - automatically rewrite NS_IF_ADDREF

Every one of these changes between A and Z leaves the repository in a broken 
state: only Z passes unit tests and works correctly. However, it would be 
extremely dumb to commit them all as one merged commit: this is because 
other people who have ongoing work will need to reproduce the automatic 
rewrites.

As another example, we often have project branches that are developed on a 
single platform: they do all the real work and make sure the unit tests all 
pass on mac, and then go back and fix up linux and windows.

This discussion has wandered rather off-topic though, no?

--BDS