据我所知，像Mercurial这样的分布式修订控制系统的一个主要优点就是你不应该担心在你的超级重要的主要仓库中破坏某些东西（很多其他开发人员都会使用它），并且做你所做的一切在你的个人远程克隆工作和研究，直到你明白一切都稳定，你可以推动你的工作。 因此我得到了一个问题：如果有可能不会推回所有的更改历史记录（您为自己制作了几个修订版），但只有一个实际上是在您的回购和当前状态之间的差异。
一个例子：
hg init master-repo; cd master-repo
echo -e 'Important file\nWith Bug!' > file
hg commit -A -m "initial commit"
cd ..; hg clone master-repo hotfix-repo; cd hotfix-repo
echo "fix1" >> file
hg commit -m "first attempt to fix bug"
echo "fix2" >> file
hg commit -m 'Fixed it!'
现在（可能在拉动并合并最新的master-repo'更改之后）我想只推回一个包含我在没有本地提交历史记录的情况下所做的所有更改的变更集。 一种可能的解决方案是再创建一个克隆，然后在两个克隆之间使用diff / patch从第一个克隆中提取/应用更改，并在第二个repo中一次性提交所有更改。然后像正常情况一样按下。但是有可能只使用mercurial命令吗？
向前谢谢！
答案 0 :(得分：5)
关于在推送之前将试错变更集合并到单个变更集是否合适的观点不同：
优点：您避免在测试套件失败的历史记录中设置更改集 - 这些更改集对hg bisect不利并添加噪音。
Con：您无法折叠已发布到其他存储库的变更集 - 这样做只会重写您的本地变更集，然后您必须手动清理其他存储库。
从技术上讲，在推送之前将一组变更集折叠为单个变更集是完全安全的。你从
开始... a --- b --- c --- x --- y --- z
然后将其重写为
... a --- b --- c --- w
其中w与z具有完全相同的存储库状态（但显然是一个不同的父变更集）。这里没有合并（因此没有合并冲突），所以它不会失败。
重写后，您可以拉动并合并上游（d和e）：
... a --- b --- c --- w --- v
\ /
d ----- e
您需要扩展程序才能执行任何类型的历史记录重写。在这里，我建议其中一个：
Collapse extension：顾名思义，此扩展程序专门用于折叠变更集。
Histedit extension：完整的历史记录编辑，但折叠命令可以折叠变更集。
Rebase extension：此标准扩展程序可以移动周围的变更集，同时折叠它们。在上面的示例中，它会在x --- y --- z之后移动e：
... a --- b --- c --- d --- e --- x' --- y' --- z'
然后，您可以选择将x'折叠为z'：
... a --- b --- c --- d --- e --- w'
与仅将x折叠为z相比，重新定位确实涉及合并，因此可能会失败。
答案 1 :(得分：3)
<强>简介
我认为，重写历史和发送/获得“抛光”变更集（以Git-boys风格）通常是一个坏主意 - 历史是历史，它有自己的价值。
毕竟，对于“主线”分支（使用分支，不是这样），所有更改都将显示为一个合并，无论更改集计数如何在分支
简短回答
没有。在Mercurial中，您可以拉/推并获得全套变更集，这会在回购历史中产生差异
答案很长
不知何故，您可以通过在交换之前将您的变更集历史记录回“另一方”。请记住 - 每个变更集代表不是新状态的对象，但差异在旧的和当前的之间（如果很快描述），因此 - 通过普通的删除更改，你可能会得到错误的最终结果
无论如何，你有很多方法可以重写自己的历史（作为扩展名）：