obliterate functionality?

Matt Mackall mpm at selenic.com
Tue Mar 18 12:58:19 CDT 2008


On Tue, 2008-03-18 at 08:55 -0700, cowwoc wrote:
> 
> 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.

'Signed' is not actually the right terminology. But every changeset
identifier is constructed from a cryptographically strong hash of every
bit in the changeset -and- its history. Change any bit in the history,
and you change every subsequent change identifier. If you actually want
to sign something with GPG, you can sign a (full) changeset ID.

> 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...?

You can either just revert the rogue changes (they can't change anything
in the history, so they're not a big deal) and live with it or you can
use pull -r or MQ's strip to build a new repo without the rogue changes.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial mailing list