汞“历史重写"后，原始变更集会发生什么情况? (histedit，提交--amend)，以及如何恢复它们? [英] What happens to original changesets after an Hg "history rewrite" (histedit, commit --amend), and how can they be recovered?

问题描述

在Git中-由于它具有不变的变更集对象和可变的refs-我知道原始提交仍然存在，这使我在经历了糟糕的"历史重写"之后感到温暖的模糊感.

In Git - with it's immutable changeset objects and mutable refs - I know that the original commits remain, which gives me a warm fuzzy feeling after an 'oops' "history rewriting" moment.

例如，在历史记录重写" git rebase之后，原始更改集(cbe7698、09c6268)仍然存在，并添加了新的更改集(08832c0).在修剪之前，我可以轻松地恢复/访问其他变更集.

For example, after a "history rewriting" git rebase the original changesets (cbe7698, 09c6268) are still there and a new changeset (08832c0) was added. I can easily restore/access the other changesets until such a time as they are pruned.

$ git log --oneline --graph --decorate $(git rev-list -g --all)
* 08832c0 (HEAD -> master) Added bar and quxx to foo.txt
| * cbe7698 Added quxx to foo.txt
| * 09c6268 Added bar to foo.txt
|/
* 895c9bb Added foo.txt

同样，即使git commit --amend也会保留原始/修改后的提交(d58dabc)并添加新的变更集:

Likewise, even a git commit --amend preserves the original/amended commit (d58dabc) and adds a new changeset:

$ git log --oneline --graph --decorate $(git rev-list -g --all)
* d9bb795 (HEAD -> master) Added cats and dogs to pets.txt
| * d58dabc Added cats to pets.txt
|/
* 08832c0 Added pets.txt

但是，在历史记录重写"操作之后，汞会发生什么变化?

原始提交是否不存在?如果它们仍然存在，如何访问和/或恢复它们?

Do the original commits cease to exist? And if they still do exist, how can they be accessed and/or recovered?

推荐答案

这取决于您是否安装了Evolution扩展.如果您安装了Evolution扩展，则唯一会真正从存储库中删除修订的命令是hg strip；否则，将删除修订.其他命令将原始提交保留在原处，但将其隐藏.您可以使用hg log --hidden(或带有--hidden标志的其他命令)查看它们.如果要永久摆脱它们，可以使用hg strip --hidden -r 'extinct()' [1].

It depends on whether you have the evolve extension installed or not. If you have the evolve extension installed, the only command that will actually remove revisions from the repository is hg strip; other commands leave the original commits in place, but hide them. You can see them with hg log --hidden (or other commands with the --hidden flag). If you want to get rid of them permanently, hg strip --hidden -r 'extinct()' can be used [1].

但是，大多数人只会使用基本的Mercurial.在这种情况下(对于hg strip，即使使用了Evolution)，删除的变更集也将作为束存储在.hg/strip-backup中. Mercurial捆绑包基本上是一个只读的覆盖存储库；您可以在其上使用hg log -R，hg tip -R，hg incoming，hg pull等.原则上这就是您所需要的，但是输入路径可能会有些麻烦.

Most people, however, will just be using base Mercurial. In this case (and for hg strip even with evolve), the removed changesets will be stored as bundles in .hg/strip-backup. A Mercurial bundle is basically a read-only overlay repository; you can use hg log -R, hg tip -R, hg incoming, hg pull, etc. on it. This is all you need in principle, but it can be a bit cumbersome typing out the paths.

为方便起见，Facebook为Mercurial发布了实验扩展数量.其中，backups扩展提供了一个便捷命令(hg backups)，该命令基本上列出了.hg/strip-backup中每个捆绑软件中的提交(类似于具有适当模板的hg incoming所做的事情)和hg backups --recover来引入变更集从剥离的提交中删除(类似于hg pull会执行的操作).

For convenience, Facebook has published a number of experimental extensions for Mercurial. Among them, the backups extension provides a convenience command (hg backups) that basically lists the commits in each bundle in .hg/strip-backup (similar to what hg incoming with an appropriate template would do) and hg backups --recover to pull in the changesets from the stripped commits (similar to what hg pull would do).

[1]请注意，即使那样，备份也将存储在.hg/strip-backup中.如果要永久删除它们，请永久删除该备份.

[1] Note that even then, a backup will be stored in .hg/strip-backup. If you want to get rid of them really permanently, you will also have to remove that backup.

这篇关于汞“历史重写"后，原始变更集会发生什么情况? (histedit，提交--amend)，以及如何恢复它们?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！