obliterate functionality?

[cowwoc]

Jens Alfke wrote:
> 
> For that reason, hg (and similar systems like Monotone and Bazaar) use  
> digital signatures to identify commits. There is deliberately no way  
> to obliterate or alter a prior commit, because it would invalidate the  
> signatures of anything that came after it. Basically, obliteration is  
> a form of tampering, that has to be prevented.
> 

Okay, I am beginning to understand. So you're saying that all data
associated with a commit is signed with a public key and that removing a
file from within that commit would require one to re-sign the data somehow
and that isn't possible. Correct? I agree this is a tough problem to solve.
I'll give it some more thought.

What happens if I pull updates from a rogue repository that corrupted or
removed some of my files? Sure I can check out versions prior to this "bad
commit" but ideally I'd like to undo pulling those changes. What would one
do in such a case? I assume that Hg lets you obliterate entire commits as
opposed to individual files...?
-- 
View this message in context: http://www.nabble.com/obliterate-functionality--tp16114445p16124275.html
Sent from the Mercurial mailing list archive at Nabble.com.