2

我们需要将 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>在同一个分支上，那么从 format-patch 生成的补丁列表可以<REV1>顺利应用回来而不会发生冲突。

我的假设正确吗？我做对了吗？

4

1 回答 1

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被调用的克隆ourbranch-REV2：

git checkout -b ourbranch-REV2 ourbranch

现在，在内核之上重新调整ourbranch自以来的新更改（即仅我们的本地更改）：REV1REV2

git rebase REV1 --onto REV2

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

于 2014-12-20T06:03:09.683 回答