2

我有一组更改可以完美地针对某个 linux 版本，比如 2.6.25.4。

我有一个 git 树，并从标签 v2.6.25.4 创建了一个跟踪分支 vanilla-2.6.25.4。我由此创建了一个名为 my-changes-2.6.25.4 的分支，并完成了我所有的工作。

现在，我想将我的工作重新建立在任意较新版本的 Linux 之上。说 2.6.28.9。实现这一目标的最佳 git 工作流程是什么？

我知道如何从 2.6.28.9 创建一个新分支，但是执行类似 'git merge my-changes-2.6.25.4' 之类的操作会引起我不感兴趣的其他事情的各种冲突。无论如何，这似乎已经坏了。

我尝试从我的工作 my-changes-2.6.25.4 创建一个新分支，并执行 git rebase 2.6.28.9，假设这会将我的更改从 2.6.25.4 应用到 2.6.28.9 之上，但这给了我很多与我所做的任何更改无关的冲突。

我不确定这样做的正确方法是什么。我正在使用稳定的 linux 树http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git，我认为一些问题可能源于事实版本化标签 v2.6.xy 并非都来自同一血统。

有谁知道如何正确地做到这一点？额外的功劳是设计了一种通过二进制搜索尽可能自动前进的方法，以找到 Linux 通过更改接口破坏我的代码的下一个位置，但我想一旦我知道我实际上想要做什么，我可以自己自动化它.

4

1 回答 1

2

您的第二种方法听起来很正确——但是您是如何调用 rebase 的？您需要告诉它您正在更改哪个是您的基本修订版。我认为你需要类似的东西

# on changes-2.6.25.4
# make new branch
git checkout -b changes-2.6.28.9
# double-check local changes to transport
git log --pretty=oneline v2.6.25.4..
# transport changes to be against new base
git rebase --onto v2.6.28.9 v2.6.25.4
# should now have the same changes
git log --pretty=oneline v2.6.28.9..

避免在变基过程中被淘汰的另一种可能性是获取本地更改列表并使用“git cherry-pick”命令将它们手动添加到基于 v2.6.28.9 的新分支中。实际上，这实际上与 rebase 相同，但从某种意义上说，您可以更好地控制自己在做什么。

我认为你关于为什么这是一个问题的推理是正确的：v2.6.28.9 不是 v2.6.25.4 的后代 - 所以默认情况下 rebase 会尝试包含 v2.6.26..v2.6.25 中的所有更改.4 和你的一样，如果你只是做了“git rebase v2.6.28.9”。单参数变基将尝试将您的本地更改作为“git log $1..HEAD”，然后将它们应用回“$1”之上 - 所以你可以看到只有当变基的参数是一个分支时才有意义已经更新。如果您像以前一样重新使用相同的标签，则不会发生任何事情。如果您使用不同的标签进行变基，您会将其他人的更改与您的更改混合在一起。您需要将一个标签重新定位到另一个标签上。

于 2009-05-27T09:00:48.790 回答