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