将实验历史记录保留在 Mercurial 中的共享存储库之外
我对 Mercurial 相当陌生，但我看到使用 Mercurial 的优点之一是，在编写功能时，您可以更自由地进行试验、签入更改、共享它们等，同时仍然为该功能维护“干净”的存储库完成的功能。
这个问题是历史问题之一。如果我尝试了 6 种不同的方法来让某些东西发挥作用，那么现在我将因所有错误而陷入所有历史记录中。我想做的是检查并清理我的更改，并将它们“折叠”到一个可以推送到共享存储库中的更改集。由于我可能从共享存储库中提取新的变更集，并将这些变更集与我自己的变更集混合在一起，这一事实使情况变得复杂。
据我所知，最好的方法是使用 hg export 创建克隆以来所做更改的补丁，克隆新的存储库，并将补丁应用到新的存储库。
这些步骤似乎有点麻烦而且很容易搞砸，特别是如果这种方法被推广到整个开发团队，其中一些人有点抵制改变（别让我开始）。 TortoiseHg 使该过程稍微好一点，因为您可以突出显示要包含在导出中的变更集。
我的问题是：我是否让事情变得比需要的更复杂？有没有更好的工作流程可以用来缓解我的麻烦？期望一个干净的历史记录（将整个（较小的）功能包含在一个变更集中）是否太过分了？
或者也许我的整个问题可以这样总结：
mercurial 中是否有等效的东西？ 折叠 git 存储库的历史记录
I'm fairly new to Mercurial, but one of the advantages I see using Mercurial is that while writing a feature you can be more free to experiment, check in changes, share them, etc, while still maintaining a "clean" repo for the finished feature.
The issue is one of history. If I tried 6 different ways to get something to work, now I'm stuck with all of the history for all my mistakes. What I'd like to do is go through and clean up my changes and "collapse" them into one changeset that can be pushed into a shared repository. This is complicated by the fact that I might pull in new changesets from the shared repository, and have those changesets intermingled with my own.
The best way I know of to do that is to use hg export to create a patch of my changes since cloning, clone a fresh repository, and apply the patch to the fresh repository.
Those steps seems a little bit cumbersome and easy to mess up, particularly if this methodology is rolled out to the whole dev team, some of whom are a little resistant to change (don't get me started). TortoiseHg makes the process slightly better since you can highlight the changesets you want to be included in an export.
My question is this: Am I making this more complex than it needs to be? Is there a better workflow I can use to ease my troubles? Is it too much to expect a clean history where entire (small-ish) features are included in one changeset?
Or maybe my whole question could be summed up this way:
Is there an equivalent for this in mercurial? Collapsing a git repository's history
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管我认为您应该重新考虑在 Mercurial 中使用分支（根据我对您帖子的评论），但使用命名分支并不能真正帮助您解决维护无用或不必要的历史记录的问题 - 它只是对它们进行了一些组织。
我建议结合使用这些工具：
，用于在推送到受祝福或主存储库之前重新处理混乱的历史记录。最简单的方法是使用
strip永久删除任何没有子项的变更集。完成后，您可以使用mq或histedit来组合、重新定位或修改现有提交。Histedit甚至可以让您重做与变更集关联的注释。一些陷阱：
在开头段落中，您提到在功能开发期间共享变更集。请理解，一旦您共享了变更集，使用 mq 或 histedit 或 strip 进行修改就不是一个好主意。使用这些扩展可能会导致修订哈希发生更改，这将使它们对其他人来说看起来像是一个新的变更集。
另外，我同意 Paul Nathan 的评论，即 mq（和 histedit）是强大的功能，可以轻松摧毁历史。在使用这些扩展之前，最好先进行安全克隆。
Although I think you should reconsider your use of branches in Mercurial (as per my comment on your post), using named branches doesn't really help with your concern of maintaining useless or unnecessary history - it just organizes them a bit.
I would recommend a combination of these tools:
to rework a messy history before pushing to a blessed or master repo. The easiest thing would be to use
stripto permanently remove any changeset with no children. Once you've done that you can usemqorhisteditto combine, relocate, or modify existing commits.Histeditwill even let you redo the comment associated with a changeset.Some pitfalls:
In your opening paragraph you mention sharing changesets during feature development. Please understand that once you've shared a changeset it's not a good idea to modify using mq or histedit, or strip. Using these extensions can result in a change to the revision hash, which will make them look like a new changeset to everyone else.
Also, I agree with Paul Nathan's comment that mq (and histedit) are power features and can easily destroy a history. It's a good idea to make a safety clone before using these extensions.
命名分支是最简单的解决方案。每个实验方法都有自己的分支。这保留了实验的历史。
下一个解决方案是为每个实验提供一个新的克隆。工作的被推回到主仓库。
下一个解决方案 - 可能是您真正想要的 - 是 mq 扩展，它可以将一系列补丁“压缩”到单个提交中。我认为 mq 是“先进的”，并且“容易搬起石头砸自己的脚”。我也不关心压缩我的提交 - 我喜欢提供我的版本历史记录以供参考。
Named branches are the simplest solution. Each experimental approach gets its own branch.This retains the history of the experiments.
The next solution is to have a fresh clone for each experiment. The working one gets pushed back to the main repo.
The next solution - and probably what you are really looking for - is the mq extension, which can "squash" a series of patches into a single commit. I consider mq to be "advanced", and "subject to accidently shooting yourself in the foot". I also don't care to squash my commits - I like having my version history present for reference.