如何修复 Mercurial 变更集注释中的错误？
如果输入了错误的信息，有没有办法重写hg commit消息？当我们提交变更集时，我们总是包含 Bug ID。例如：
hg commit -m“Bug 14585：LastName字段应该是强制性的”
但是如果我输入了错误的错误ID，有没有办法（可能通过扩展）在更改集后修复评论已提交并推送至中央仓库？
Is there a way to rewrite the hg commit message if the wrong information was entered? We always include our Bug ID when we commit a changeset. For instance:
hg commit -m "Bug 14585: LastName field should be mandatory"
But If I put the wrong bug ID, is there a way (through an extension maybe) to fix the comment once the changeset has been committed and pushed to a central repo?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Mercurial 中的变更集故意是不可变的。如果您从那时起就已提交，则不可以，您无法更改该修订版的文件。不过，有一个编辑历史记录的指南，但是要非常非常非常 小心不要在此过程中搞砸你的仓库。
看起来您只想编辑提交消息，您也许可以做到。
Changesets in Mercurial are deliberately immutable. If you have committed since that, no, you can't change that revision's files. However, there is a guide to edit the history, but take very, very very good care to not screw up your repo in the process.
It seems like you just want to edit the commit message, which you may be able to do.
我找到了一种修复提交消息的方法如果错误的变更集仍然是存储库的提示。
假设变更集 24 有无效注释。还假设该变更集中涉及 file1.txt。您可以向 file1.txt 提交虚假更改，然后折叠包含不正确变更集的虚假变更集并提供新消息。
这是一个 hack，但它完成了工作并且没有留下任何更正的痕迹。创建一个扩展来做到这一点并将其变成一个易于使用的解决方案可能不会太难。
I found a way to fix a commit message IF the incorrect changeset is still the tip of the repo.
Suppose changeset 24 has an invalid comment. Also suppose that file1.txt was involved in that changeset. You can commit a fake change to file1.txt and then collapse the fake changeset with the incorrect changeset and provide a new message.
It's a hack but it does the job and leaves no trace of the correction. It would probably not be too hard to create an extension to do that and turn this into an easy to use solution.
如果回滚&重新提交不是一个选项，或者您已经将更改推送到上游，因此 histedit 扩展 本身没有帮助，那么 Mercurials 不可变的历史会给你带来问题。无论你做什么，你都会留下明显中毒的悬挂分支，不需要的变更集可能会重新出现-随时注入到您的存储库中。
修复错误
如果您处于这种情况，那么您有几个选择，具体取决于更改传播的程度以及更改集的回溯程度。
我过去曾使用过这两种方法。
使用同级分支进行修复并弃用/删除旧分支
如果只有几个变更集，并且由于某种原因无法使用 histedit 扩展，则可以将这些变更集导出为补丁并将其重新应用到父分支。对于第一个变更集（您想要更改其历史记录的变更集），您需要使用
hg patch --no-commit，然后使用新消息使用hg commit。然后剩下的，只需使用hg patch按原样导入更改和提交消息。这种方法的问题是，您最终会得到两个分支，其中一个分支需要永远忽略（我会更新到错误的变更集，并将该分支标记为已弃用，然后再切换回固定分支）。
或者，您需要找到包含此分支的每个存储库并对其进行
hg strip。这里的问题是，某些机器可能没有启用 Mercurial Queues 扩展，如果您错过了一个存储库，并且该存储库与另一个存储库同步，则更改将开始重新传播。使用子分支修复并合并后续更改
如果更改集已经传播得太远，您可以尝试更新到受影响的修订版，强制进行虚拟提交，并在该提交消息中解释先前提交消息的问题。然后可以将此变更集与您当前的分支提示合并，以使所有内容保持最新。
例如，如果错误消息是“Closes #5234”，而它应该是“Closes #5324”，则子消息可能是“Uncloses #5234，Closes #5324”。
If a rollback & re-commit isn't an option, or you have already pushed your changes upstream, so the histedit extension on its own won't help, then mercurials immutable history will cause you problems. Whatever you do you will be left with either hanging branches which are explicitly poisoned unwanted changesets might be re-injected into your repository at any time.
Fixing errors
If you are in this situations then you have a couple of options, depending on how far the changes have propagated and how far back the changeset is.
I have used both of these methods in the past.
Fix with a sibling branch and deprecate/strip the old one
If it is only a few changesets, and you can't use the hitsedit extension for some reason, you could export those changesets as patches and re-apply them to the parent. For the first changeset (the one whose history you want to change) you will need to use
hg patch --no-commit, and thenhg commitwith the new message. Then for the rest, just usehg patchto import the changes and the commit message as-is.The problem with this method is that you end up with two branches, one of which you will need to ignore forever (I would update to the faulty changeset and tag the branch as deprecated before switching back to the fixed branch).
Alternatively, you need to find every repository which contains this branch and
hg stripit. The problem here is that some machines might not have the Mercurial Queues extension enabled and if you miss even one repo, and that repo is synced with another, the changes start to re-propogate.Fix with a child branch and merge in subsequent changes
If the changeset has already propagated too far, you could try updating to the affected revision, forcing a dummy commit and in that commit message, explain what was wrong with the previous commit message. This changeset can then be merged with your current branch tip to bring everything up to date.
For instance, if the incorrect message was "Closes #5234" and it should have been "Closes #5324" then the child message could be "Uncloses #5234, Closes #5324".
如果您没有对存储库执行任何其他操作，则可以执行“hg rollback”并重新提交。
If you haven't done anything else to your repository, you can do an "hg rollback" and just re-commit.
histedit 扩展可能就是您正在寻找的。它允许您在事后编辑提交消息。它还允许您删除或折叠修订，就像 git rebase --interactive 一样。
请注意，您必须在要修复的存储库上启用并使用该扩展；无法编辑远程存储库的历史记录。此外，我在中央存储库上使用它时会非常谨慎。正如 Tim Post 指出的那样，善变的变更集并不意味着要改变。
The histedit extension might be what you are looking for. It allows you to edit commit messages after the fact. It also allows you to drop or fold revisions, much like
git rebase --interactive.Note that you have to enable and use the extension on the repo you'd like to fix; there is no way to edit the history of a remote repo. Additionally, I'd be very cautious about using this on a central repo. As Tim Post points out, mercurial changesets are not meant to be changed.