cowwoc at bbs.darktech.org
Tue Mar 18 10:55:25 CDT 2008
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.
More information about the Mercurial