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

直接的git回答，可能错了：

在merge-branch创建新分支REV2，然后在REV2之上重新定义比祖先更新的REV1更改（因此不在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的直接祖先，因为这些内核实际上是分支。但是，您不必处理这些变更管理细节。您需要做的只是在REV1之上修改针对REV2所做的更改。

假设您有ourbranch内核开发从REV1发出：

首先，创建一个名为ourbranch的{{1}}克隆：

ourbranch-REV2

现在，在git checkout -b ourbranch-REV2 ourbranch内核之上重新定义自ourbranch以来的新REV1更改（即仅我们的本地更改）：

REV2

如果一切顺利，您可以git rebase REV1 --onto REV2重写ourbranch-REV2历史记录，就好像它已经在ourbranch内核上开发一样。

git补丁适用导致冲突？

1 个答案:

直接的git回答，可能错了：

更大的图片：