mercurial - 在 Mercurial 中如何做而不是压缩提交

Question

每次保存任何内容时，我都将 IDE 设置为在本地提交。理想情况下，我希望保留一份未经审查的记录，记录我的白痴摸索，以便在极少数情况下它们可能有用。但大多数时候它使我的历史变得详细。

我想知道一个很好的策略来保留那个历史，但大多数时候能够忽略它。每次保存时，我的 IDE 都会运行我自己的脚本，所以我可以控制它。

我对 Mercurial 还很陌生，所以在这里我可能只需要一个基本的答案。但是，在提交、 merge 和报告时，我应该执行哪些步骤才能大部分时间忽略这些自动提交，但又不会实际压缩它们？还是我最好放弃并只是压扁？

Related question about how to squash with highly rated comment suggesting it might be better to keep that history

编辑 - 我的观点是，如果 Mercurial 想要保留您的所有历史记录(我同意这一点)，它应该让您过滤该历史记录以避免看到您可能想要压扁的东西。我不想压扁，我只是寻求一种策略的帮助(在常规使用中，虽然并非总是如此)让它看起来尽可能像我压扁我的历史一样。

Answer 1

您想在您的存储库中保留详细历史记录，但您希望拥有(并能够导出)仅包含“合理”revsets 的理想化历史记录，对吗？我可以同情。

解决方案1:使用标签来标记历史中的有趣点，并学会忽略它们之间的所有杂乱点。

解决方案2:使用两个分支并 merge 。在分支中进行开发 default ，并保持一个并行分支 release . (您可以将其称为 clean ，但实际上您正在管理版本)。每当 default处于稳定状态想要checkpoint，切换到分支release并将 default 的当前状态 merge 到其中-- 如果您愿意，可以分批进行。如果您从不直接向 release 提交任何内容，永远不会有 merge 冲突。

 (original branch) --o--o--o--o--o--o--o    (default)
          \              \        \
           r   ... ...  --r--------r        (release)

结果:您可以更新到 release 的任何修订版并期待一个功能状态。您可以运行 hg log -r release并且您只会看到所选的检查点。您可以检查完整的日志以了解一切是如何发生的。缺点:因为 release分支依赖于 default ，如果不带 default，就不能将其推送到另一个存储库用它。还有 hg glog -r release由于重复 merge ，看起来会很奇怪。

解决方案 3:使用上述命名分支，但使用 rebase扩展而不是 merge 。它可以选择复制，而不是彻底移动，重新定位的变更集；它有一个选项 --collapse这会将一组修订转换为单个修订。每当您有一组修订时 r1:tip您想完成，请从 default 复制它们至 release如下:

hg rebase --source r1 --dest release --keep --collapse

这插入了 release 头部的 ONE 修订这相当于从 r1 到 default 头部的整个变更集. --keep选项使其成为副本，而不是破坏性的重写。优点是 release分支看起来就像你想要的一样:漂亮干净，你可以推送它而无需拖动默认分支。缺点是您无法将其阶段与 default 中的修订联系起来。 ，所以我建议使用方法 2，除非您真的必须隐藏中间修订版。 (另外:分批压缩历史记录并不容易，因为 rebase 将移动/复制“源”修订版的所有后代。)

所有这些都需要您做一些额外的工作。这是不可避免的，因为 mercurial 无法知道您想要压缩哪些 revset。