Use Cases
Prepending History
A company converts a repository to Mercurial but doesn't preserve history in the original repo. e.g. they copy code from a CVS repository to a Mercurial repository as revision 0. Later, they want to convert the existing history to Mercurial and expose it as a single history while preserving revision nodes (so a flag day isn't required and people don't have to mass convert repos).
Fixing Bad History / Form of commit censorship
Someone did something wrong. They merged against the wrong parent. They committed something they shouldn't have. People would like a mechanism to amend published history to remove bad commits from existence. They could do this by pointing the first good commit after badness to the last good commit before badness. e.g.
A -> B -> C -> D -> E
Say C is bad. We could rewrite the p1 of D to point to B, omitting C from history.
A -> B -> D -> E
Proposal
The proposal is to create a mechanism to allow "fake parent" data in changelog entries. A changeset will be rewritten to refer to a different parent.
This will invalidate the hash of the rewritten changeset. However, all descendent changesets will still verify because their manifests and parents will be valid.
There will need to be a mechanism to describe which changesets have been rewritten - which changesets whose hash cannot be trusted. This is doable via several means. However, there are security implications. A MitM could potentially rewrite changesets during transport to indicate that hashes cannot be trusted. They could also rewrite content at the same time, subtly introducing backdoors or vulnerabilities without existing hash verification catching it.