问题标签 [git-bisect]

我正在像这样运行 bisect （尝试用 , 代替subprocess，以获得良好的效果。相同的结果......）：

并得到

在最后一个命令上。如果我交换好的和坏的，我会再次收到最后一个命令的错误。如果我忽略，我可以运行我的测试，但是当我输入一个好/坏的命令时，我会再次收到这个错误......

直接从 bash 运行不会出现任何错误：

Python 3.5.2，混帐 2.7.4

更新：

将我的 bisect start 更改为 bisect start BAD GOOD似乎工作正常，但我不明白为什么

我有一个tests.sh文件。
该文件仅包含exit 0或exit 1。0对于前几个提交，1剩下的（我认为）表示前几个提交是good，其余的是bad.

我在跑步$ git bisect run ./tests.sh。但是它告诉我我需要从git bisect start.

我试过git bisect start先跑步，然后说这HEAD是不好的，但没有成功。

我在这里做错了什么？

我在工作中遇到了一个情况，我们有一个 git repo，有大约 80 个活跃用户在工作。在修改文件的功能分支上有一个提交 #1。分支合并到master。一段时间后，我发现 master 上缺少由 commit #1 引入的更改。因此，我git bisect将提交 #1 指向好，而当前的 master 则指向坏。

经过一些步骤后，git bisect 发现要归咎于损失的提交是几个月前在另一个功能分支上的一些提交，涉及完全不同的代码区域。

我一次又一次地跑这个平分。我也要求我的同事这样做。每次相同的提交都出来了。

我们无法解释这种行为。手动调查历史记录和文件更改非常困难，因为历史记录非常庞大，分支之间有许多合并。

最近我的同事在另一个代码区域中遇到了另一个丢失的代码的类似问题。再次 bisect 归咎于不相关的提交。

我完全不知道发生了什么。

当我在我feature的分支上工作时，ci分支已经向前运行了。当我重新定位feature到ci时，测试失败。我想找到ci我的分支开始失败的提交。

我可以编写一个脚本，对 .rebase 进行feature变基，运行测试，然后将分支重置回变基之前的点。然后，它可以与git bisect run <this script>. 但这看起来像一个模式，有没有现成的命令呢？

我正在使用 git bisect 找出 VERSION 文件已从 0.0.1_testing 更改为较新版本的版本，我想像这样使用bisect run。

git bisect run sh -c 'if [ "$(cat VERSION)" == "0.0.1_testing" ] ; then exit 0 ; else exit 1 ; fi'

但是我一直得到不好的结果并且这个错误sh: 1: [: 0.1.0: unexpected operator（0.1.0由返回"$(cat VERSION)"。我认为这是因为当子shell退出时，bisect使用它的退出值并且甚至没有通过脚本的其余部分。

有没有办法让这个工作？或者有什么好的选择？我知道我可以使用除 bisect 之外的其他工具，但我真的很想这样做。

我有一个包含复杂分支和合并树的存储库，我想使用 git bisect 来查找何时引入了错误。

我有一个好的提交和坏的提交来开始平分，其中好的提交是坏提交的祖先。

我希望git bisect去提交具有良好提交作为祖先的提交，但它没有（使用 git 2.21.0）。

目前，我通过保留提交列表并git rev-list --ancestry-path GOOD..BAD在中间使用和选择提交来手动进行平分。有没有办法自动化这个git bisect？它有一个标志可以留在祖先的道路上吗？

首先在祖先路径中二等分的推理

与正在搜索的错误相关的功能可能并不存在于所有分支中，因此检查在那里无关紧要。不过，它们应该存在于祖先路径中。

一旦完成了祖先路径的二分，一个人可能会得到一个合并提交作为责备，他们会知道这个错误来自那个分支。这已经教会了人们很多关于这个错误的知识。

要继续对引入错误的分支进行二等分，不需要单独测试每个提交（因为它们不一定具有出现错误所需的功能），但应该将每个提交与最后一个好的提交合并然后检查是否存在错误。然后可以查明一个特定的提交，当它与好的提交合并时，会引入错误。

请注意，我已经多次完成此过程，它对我非常有用，我只是在寻找使其更方便的方法。

我正在学习git bisect

让我们猜测以下线性 git 历史：

然后，我开始二分：

我有一个运行一些测试的脚本，如果我手动运行测试并将每个提交标记为bad和good，它遵循以下步骤：

因此，它完成D commit-4了第一个错误提交，这是正确的。

但是，如果我使用git bisect run ../outside/test.sh它会执行以下操作：

说这A commit-1是第一个错误的提交，这是错误的。

所以，如果我理解这里的二进制搜索，一次C commit-3是坏的，第一个错误的提交应该是它自己或者在下面。

我在这里缺少什么？为什么他们会有不同的行为？看起来git bisect run正在运行不同的算法。

我的 git 版本是：2.19.0

谢谢

我正在尝试git bisect从已编辑的日志中重播一个以撤消我犯的错误。

我错误地将其中一个提交标记为好，而它本应该是坏的（反之亦然）。我跑了：

然后我编辑了该文件以删除错误标记的提交和下面的所有行。

然后我跑了：

我现在收到错误：

到底是怎么回事？我如何解决它？（为什么在修订的末尾有一个“？”？）

我在 Windows 10 上使用 git 版本 2.26.2.windows.1。我使用 PowerShell 7 作为我的 shell。

我试图避免在这里编写我自己的 bisect 工具，但我想我会先在这里检查一下。

基本上，我只想平分列出的提交git log --merges（即我想弄清楚哪个 PR 引入了问题）。但是，git bisect似乎使用所有提交，而不仅仅是 PR 合并提交。这是有问题的，因为测试提交是好是坏对于除了 PR 合并提交（预先构建在工件中）之外的任何东西都是极其繁重的。

使用这里git skip建议的剔除非合并提交是次优的，而不是真正的合并提交的二进制搜索。例如，我使用了这种方法，这是平分所采用的路径（这是合并提交的列表，星号是问题合并提交，数字是平分所采用的路径）：git skip

我可以生成一个我想要一分为二的提交列表git log --merges，但是是否有可能以某种方式将该列表提供给它，git bisect以便它可以最佳地一分为二，还是我不走运？

我想了解什么是 SVN bisect / git-bisect 算法。我尝试搜索在线资源，但无法获得好的问题陈述和解决方案。