git补丁应用导致冲突

Question

我们需要将android的内核从<REV1>升级到<REV2>。

我正在尝试生成两个<REV1>和<REV2>之间的补丁列表。所以我检查了两者是否在同一个分支上，以使用命令获得补丁列表

$git merge-base 69ecc39b5b4ea78de1f25bf9cbe7c236a91f764c af5ddc99f3d0e7c2406d5bf64763eef7d0843127

发现它们不在同一个分支上。因为我得到了<REV1>和<REV2>的第一个共同祖先c4b646ff80f558010ee486421ee1b718db1a3193

因此，我尝试使用在共同祖先和<REV2>之间生成一个补丁列表

$git format-patch c4b646ff80f558010ee486421ee1b718db1a3193..af5ddc99f3d0e7c2406d5bf64763eef7d0843127 -o patch_JUN15_NOV26

现在我创建了一个新分支，并将其重置为共同祖先提交

$git reset --hard c4b646ff80f558010ee486421ee1b718db1a319

现在我试着修补这个分支上的整个补丁列表：

$git am --ignore-whitespace --reject ../../jb/kernel/patch_JUN15_APR10/*

但我收到了补丁失败的错误，要求我解决补丁列表中第一个补丁的冲突。但我预计不会有冲突。我的假设是，如果<REV1>和<REV2>在同一个分支上，那么从格式补丁生成的补丁列表可以顺利地应用回<REV1>，而不会发生冲突。

我的假设正确吗？我这样做对吗？

Answer 1

直接的数字答案，可能是错误的：

在REV2创建新的分支merge-branch，然后在REV1:之上重新设置REV2比祖先（因此不在REV1中）更新的基础

git checkout -b merge-branch <rev2-hash>
git rebase <ancestor-hash> --onto <rev1-hash>
             ^                        ^
             |                         
             |                          `play them on top of this
              `take commits from this
               far back in the current branch
      ... and plant the result as the replacement for the current branch

总体情况：

为什么上面的答案可能是错误的，我猜，和许多人一样，你是一个小组织，为你的产品维护一些内核定制，并且你想升级到一个更新的内核。您的自定义基于REV1，现在您想将该工作转移到REV2。如果是这种情况，那么处理REV1和REV2之间的合并完全是错误的问题。这已经在上游得到了处理。Upstream产生了两个非常好的内核：REV1和REV2。REV1不是REV2的直接祖先，因为这些内核实际上是分支。但您不必处理这些变更管理细节。您所需要做的就是在REV2之上重新设置针对REV1所做的更改的基础。

假设你有内核开发的ourbranch，它源于REV1:

首先，创建一个名为ourbranch-REV2:的ourbranch克隆

git checkout -b ourbranch-REV2 ourbranch

现在，在REV2内核之上重新设置自REV1以来新的ourbranch更改（即仅我们的本地更改）：

git rebase REV1 --onto REV2

如果一切顺利，您就有了ourbranch-REV2，这是您的ourbranch历史，就像它是在REV2内核上开发的一样。