我很懒，想用 git bisect 找到一个提交，它引入了尽可能少的工作失败。
我认为自己没有理由提供良好的哈希值。
我认为这些输入应该足够了：
- 一个脚本，成功返回 0，失败返回其他
- git 在一个分支上（不是分离的头）。并且测试失败
工具 bisect（或包装器）可以跳回 git 历史以找到一个好的散列本身。
问题：如何完成这项工作？
问问题
114 次
2 回答
0
跳回 git 历史以找到一个好的哈希本身
这听起来很简单：运行你的脚本 for master~1, then master~2, master~4... etc 直到它返回 0 或带你到原始提交（它应该找不到提交，然后通过二等分你会找到最大的 N 以便 master~N仍然有效）。
但我不确定你会对此感到满意：
- 您最终可以进入之前的测试休息时间。然后随后的二等分可能会给您不正确的结果。如果您不对历史做出任何假设，那么除了检查每个提交之外的任何序列都有这种风险。
- 如果您没有以任何良好的修订版本运行它，您如何确定该脚本是正确的？
于 2016-03-04T20:08:33.373 回答
0
这正是 bisect 所做的。
您可以将脚本传递给它以运行并且脚本返回0或1好坏。
你还想让 bisect 为你做什么？
只需阅读文档：
Bisect run
如果您有一个可以判断当前源代码是好还是坏的脚本，您可以通过发出命令一分为二：
git bisect run my_script arguments
请注意，如果当前源代码为good/old，则脚本（上例中的 my_script ）应以代码 0 退出，并以介于
1和127（包括）之间的代码退出，除非125当前源代码为bad/new。任何其他退出代码都将中止 bisect 过程。
125当无法测试当前源代码时，应使用特殊退出代码。如果脚本使用此代码退出，则将跳过当前版本（请参阅上面的 git bisect skip）。
125被选为用于此目的的最高合理值，因为126和127被 POSIX shell 用于指示特定的错误状态（127用于未找到命令，126用于已找到但不可执行的命令——这些细节无关紧要，因为它们是脚本中的正常错误，就 bisect run 而言）。
于 2016-03-02T09:36:35.650 回答