Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I gave a talk about it at our local Python user group. AMA:

https://www.youtube.com/watch?v=4OlDm3akbqg



Is history modifying rebase going away? If I accidently commit "the keys to the kingdom" how do I get them out of the history?


> Is history modifying rebase going away?

In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general.

With evolve, the obsolete commits stay around foreverish, but they slowly fade from history as new people clone or pull, since obsolete commits don't get pulled or pushed by default.

> If I accidently commit "the keys to the kingdom" how do I get them out of the history?

Mercurial never actually removes any functionality, since it's got the deepest commitment to backwards compatibility I've ever seen. Thus, you will delete commits the same way you do now: hg strip --no-backup. That deletes commits with extreme prejudice, locally. Now you just have to run this in every copy of your repo, including remote ones, but the genie-out-of-the-bottle problem is one you can't avoid with a DVCS.


> In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general.

rebase doesn't mean "rewrite commits", it means "create new commits based on these ones, based of a new base". Your original commits are still there, and are pushed to the remote, but are GCed after a certain period (default 30 days?) if they are not referenced from anywhere. Since unreferenced commits are pushed to the remote, you can easily restore those commits within the GC period.


When you rewrite a book and create a new edition, you don't typically recall the old editions. A rewrite needn't be destructive.

My point is that git says "rebase" even when the underlying base of the commits affected is not changing. This is an artifact of the UI, since the command to rewrite in git is typically git rebase -i.


You can still permanently delete a changeset using `hg strip`. Of course if you have pushed that changeset you will need to run `hg strip` on all remote repositories that have a copy of the commit.

Mercurial will also (very helpfully) create a backup bundle of the changeset you strip, so you will need to securely erase that as well.


If you've accidentally published a key, your only safe option is to change that key. Abolishing it from history is closing the gate after the proverbial horse is well into the distance.


This is what I was wondering. Is it possible to do this with mercurial? I am thinking that it is, but the evolution thing is a way to handle other types of rebase situations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: