Checkpoints are in checkpoints.cpp.  As of 0.7.1, the latest was 193,000.  I'm not sure if 0.7.2 moved it up.

There are problems with limiting rollback.  I've proposed a scheme where reorgs become exponentially more costly, but it still has the problem that it adds new state to the system and messes with automatic convergence.

There is no limit. Actually there is no "rollback" at all.

Why this 120 block thing? It is just the number of confirmations required to spend mined coins, nothing more. Totally unrelated to "rollback"

As long as someone have a backup blockchain (for example if the 51% attack use a chain where the modifies start 6 months ago or a year ago in the chain) we are totally fine.

Yes, this will require a fix in the client to tell the client "ehi ignore the wrong chain" 

Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.

I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.

I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.

How could they do this if there was a limit.  Wouldn't the limit prevent those on the shorter chain from being rolled back to ump to the longer chain?

They will manually delete the x last blocks and download the longest chain.

How would mining software know which chain is legitimate and which chain is not?  How would mining software look at a brand new block and say "oh, hey, this one's not legit!"?

That's the whole reason for automatically choosing the longest chain in the first place - it is assumed that the longest chain is the legitimate chain.  If not the longest, then how does your mining software determine which chain to mine on?

A human will know it.

This isn't to protect against double spends. It's for protecting against a government building a new blockchain for months and release it, killing Bitcoin.

Ok, let's build off of that scenario.

The government builds a new blockchain and releases it.  Suddenly, months of transactions are reversed.  People realize the problem, and put a plan into action.  A new QT client is released with a hardcoded block checkpoint of the last legitimate block mined.  Half of everyone using Bitcoin quickly switches to it, the other half slowly switches over.

But here's the question:  If the government could build a new blockchain for months and release it, then they must have more hashpower than the rest of the network combined.  What is stopping them from messing with the legitimate blockchain from the hardcoded checkpoint on forward?  If the checkpoint is block 240,000, how would a miner know whether block 240,001 came from the government or came from a legitimate miner?