【问题标题】:kernel: bisect merge commits to find non-merge first bad内核:平分合并提交以查找非合并优先错误
【发布时间】:2021-08-28 19:56:18
【问题描述】:

我在内核中将问题一分为二,第一个错误提交merge 提交:

2b90506a8186 的父母(都):

还有v5.12-rc2 很好

我需要做第二个二等分来找到实际的第一个非合并错误提交(即028a1e968435..2b90506a8186 - 4885 提交或01d713689441..2b90506a8186 - 46 提交之一)。

我记得之前在类似的情况下,我签出到其中一个父级(第一个分支)并在第一个分支的顶部逐个应用来自另一个父级(第二个分支)的所有提交。有了这个特殊的分支,我需要解决一些冲突,因为历史是线性的。

但我不记得我是如何从另一个父母那里得到提交列表的。 这可能很简单,用 git log --first-parent 创建它的父级。

但对于这种情况,我无法生成列表,可能是由于父母也是合并提交。

我尝试阅读各种资料,但没有成功:

更新我不相信所有设备都存在内核回归,只是我的特定 arm64 设备的设备树存在问题。找到有问题的提交可以帮助我暂时恢复有问题的提交,直到我在我的设备的设备树中找到需要修复的内容。

【问题讨论】:

  • (a) 你的好坏测试是什么? (b) 你的问题是什么? 2b90506 与父母双方没有任何差异,合并没有什么不寻常的地方。请具体说明,编辑:不仅仅是你在看哪里或你如何解释你所看到的,而是你在看什么以及你在寻找什么。
  • @jthill (b) 我需要做第二个二等分来找到实际的第一个非合并错误提交。整个问题是,围绕第一个坏的合并提交太多,我感到困惑 :) (a) good:我的设备正在启动,bad:设备在启动过程中。

标签: git version-control linux-kernel bisect


【解决方案1】:

2b90506a8186 的父母(都很好):[...] 我需要做第二个平分来找到实际的第一个非合并错误提交

您知道合并 2b90506^2 会生成一个无法在您的设备上启动的内核,因此该提交具有将在集成中出现的错误:这很糟糕。

git bisect 2b90506^2 $(git merge-base 2b90506^1 2b90506^2)

在测试时,首先合并到 2b90506^1 以检查提交是否会通过集成测试,因为那是您真正的“坏”情况。

【讨论】:

  • 是的,将它一分为二不是魔术。但是为什么它很棘手是一些“错误”(特定设备的问题)在某些提交的组合中表现出来。我想当从一个父级线性添加所有提交到另一个父级的顶部时,我必须制作我的树。因为我已经将git bisect 2b90506^2 $(git merge-base 2b90506^1 2b90506^2)一分为二了。
  • 但是为merge-base +1,我不知道这个。
  • 我的建议是您测试将每个提交与 2b90506^1 合并的结果,以确定它是否好。您在问题中说 2b90506^2 是“好”,但您知道将它与 ^1 合并会导致内核损坏。这样不好。这就是你在平分时应该做的测试。
猜你喜欢
  • 1970-01-01
  • 2020-05-12
  • 1970-01-01
  • 2015-02-26
  • 1970-01-01
  • 1970-01-01
  • 2011-09-04
  • 2016-10-09
  • 2011-09-05
相关资源
最近更新 更多