问题标签 [rebase]

当我尝试时hg rebase -s 1775 --collapse，我被要求合并自 rev 1774 以来我接触过的所有文件。我怎样才能避免这种情况？

细节

我只是在学习如何变基。我成功地尝试了这里给出的例子，以及一些小的变化。但是，在我自己的存储库中，当我尝试相同的步骤时，我被要求在 rebase 时合并大量文件。这就是我所做的。我究竟做错了什么？

我想可能是因为我已经更新到-r1774，所以我在标记-r1774后更新了小费。结果相同。

hg tag创建一个新的 rev -r1784 。所以我尝试专门更新到-r1783。结果相同。

我在网上搜索了相关问题，但没有找到任何东西，这并不意味着答案不存在。欢迎指出现有答案。

编辑：

这似乎与1.4 中修复的报告的 mercurial 错误有关。我有 1.1 版。我尝试更新到 1.4 或更高版本，但sudo apt-get install mercurial说我有最新的，并且mercurial 页面上的下载链接目前已损坏。所以也许答案只是获得最新版本，但希望有另一种解决方法。

我之前通过创建一个克隆并在克隆中执行 rebase 来完成此操作，但我怀疑我可以在单独的分支上安全地执行此操作。

我有一个功能分支feat-x，上面有大约 25 个提交。我想（安全地）将其中的几个压缩在一起。

（我说“安全”是因为前几次我压扁的时候我没有把它弄好——但是在克隆中工作，所以把它扔掉，直到我想出正确的咒语。）

什么样的命令序列会给我feat-x-exp一个副本，feat-x这样我就可以在不干扰的情况下尝试挤压feat-x？

我在 github 上有一个开源 ruby​​ 项目，其中我的 master 分支代表已发布的内容，我的 dev 分支代表接下来将发布的内容。

master 分支在 dev 分支后面大约有 80 多个提交，而 dev 分支包含相当重要的架构更改。

一位贡献者向我发送了基于主分支所做更改的拉取请求。我想将这些更改拉到我的开发分支中，而不必重新编写它们或进行大量的合并冲突解决方案（这实际上是在重写这些更改）。

处理这种情况的最佳做法是什么？

当我尝试将上游分支重新设置为主题分支时遇到问题。工作流程是这样的：

结果如下所示：

昨天发生在我身上，我做了我的研究并没有发现任何东西，所以最后我使用git merge upstream了而不是git rebase upstream并且事情奏效了。真正的问题是今天也出现了错误。由于昨天的合并，我已经与上游同步。另外，我从昨天开始就没有修改过队友介绍的文件。

我的 Git 版本是 1.5.6.5（并且真的不想在这台机器上更新它，我担心会产生不良后果）。

所以，昨天我发布了一个关于一些奇怪冲突的问题，当我试图将上游分支重新定位到我的本地主题分支时。

最后，我使用git rebase --merge upstream并解决了自上次 rebase 以来我没有接触过的文件中的很多冲突。

在这种情况下，我对 rebase 的理解是它将我的提交与该主题分支分离，应用来自上游分支的提交，然后将我的提交（作为补丁）应用到这些之上。因此，它最终成为一个快进操作。我不明白的是......为什么我会与来自上游的提交发生合并冲突。那些也作为补丁应用吗？我认为只是......在来自同一分支的先前提交之上“焊接”一些提交的行为？

我问这个是因为我在我没有接触过的文件中有很多冲突。哦，我每天都用这个上游分支做 rebase。

更新

我刚刚注意到从上游带到我的主题分支的一些提交更改了它们的 SHA-1 id。有谁知道什么可能导致 Git 这样做？会不会是--merge开关？

我的 git 版本是 1.5.6.5

好吧，我几乎想通了这个变基的事情。

我能感觉到即将到来的突破——这里是转折点：

我如何做一个变基从：

到：

我不只是想将 HEAD~1 合并到 branch1，我想我想重新设置 branch1 对吗？

我觉得我几乎想通了——救命！？

我从 master 创建了一个“功能”分支并工作了很长时间。然后，我获取了最新的主分支提交，并在其之上重新定位了我的“功能”分支提交。然后我将“功能”合并到master中。但是，我忘记了合并并继续提交到“功能”分支。我现在希望将这些提交放在一个新分支中，所以我现在想创建另一个分支“feature_2”，它基于自上次合并到 master 以来“feature”分支上的提交。有什么建议么？

我们有一个为每个客户定制的基础系统。基础存在于自己的存储库中，每个客户端都存在于自己的存储库中（最初是从基础克隆的）。

目标是能够根据需要向基础添加错误修复/功能，可以将其传播给客户端。

到目前为止，工作流程如下：

• 为基本修复/功能制作提交/主题分支：（基于基础，主）git commit -m "Fix admin typo"
• 将这些更改合并到客户端： (on client, master) git merge base/master。显然，这包括修复基础和客户端自定义之间的任何冲突。
• 将合并推送到客户端的原点：（在客户端，主控）git push origin master
• 我们的约定是使用 rebase 进行拉取（以保持历史可读性）。因此，在客户端项目上工作的不同开发人员将（在客户端，主控）git pull --rebase origin master

正是在这一点上，我们遇到了 pull/rebase 的重大问题。在从基础合并到客户端后，开发人员会在 pull/rebase 中遇到冲突。而且它不仅仅是一些冲突，还有很多（对于许多被重放的提交？），并且通常是特定开发人员甚至从未接触过的代码。我认为这是不合理和不可持续的。

这里最好的解决方案是什么？

我唯一的想法是在拉取和处理草率和难以阅读的日志时停止使用 rebase，但我宁愿不必这样做。这些客户项目可以持续多年，我希望将来能够从基础系统合并中获得一些意义。

从 VS2008（对吗？）开始，MSVC 链接器选项具有基地址随机化。

这个功能的主要目的是什么？

我唯一高兴的是，我不再需要手动重新设置我的 Dll。

这就是全部？这是他们的目的吗？
有没有其他的好处。

基本上，我想尝试的是将 hg 修订版从实验性 repo 的一个分支拉到主线的克隆中。但我想丢弃分支名称，以便可以直接推送到服务器端主线 repo。最好举一个简单的例子：

如您所见，主线现在包含一个带有“branch: bar_branch”的 rev。我不希望这个版本有一个分支（即它应该是默认的）。

如果这需要使用rebase、移植或其他工具重写历史记录，那也没关系。我已经尝试了这两种方法，但无法正常工作。两个存储库之间的最新修订哈希可能最终不同。

所以我希望 hg_mainline 的最高版本看起来像：

没有命名的分支。

同样，如果没有从 hg_experimental 中保留哈希，也没关系。

我目前正在使用来自 Ubuntu PPA 的 hg 1.6.2+55-18e1e7520b67。

编辑：

我也用过 1.3.1。我对两者都进行了以下测试，这里的结果是相同的。

我让它与移植一起工作，但仅限于grep -vkludge。

和：

无论有没有合适的 grep，hg export 都不起作用。

变更集补丁看起来像：

我从实验中导出：

并尝试通过以下方式导入主线：

它失败了：

编辑2：

如前所述，导出方法失败只是因为文件为空。它适用于--git或适用于非空文件。