以上并不必互相排斥,我可以先找出引起该 bug 的标签,然后在该标签上重新运行另一个 git bisect。
以上并不必互相排斥,我可以先找出引起该 bug 的标签,然后在该标签上重新运行另一个 git bisect。
如果您有一组标签的总订单,您可以在 git bisect
会话中只需使用 git bisect skip [range]
或 git bisect skip [range] [range] [range] ...
— 其中每个 [range]
将是 tag1..tag2~1
、tag2..tag3~1
等等。
git bisect
"(man) 在准备开始计算实际二分时过于沉默,这已在 Git 2.37(2022 年第三季度)中得到了纠正。cdown
) 提交。gitster
-- 进行合并,日期为2022年5月20日)
bisect:在我们准备计算二分法之前输出状态。 由Chris Down签署
Commit 73c6de0 (
bisect
: don't use invalid oid as rev when starting, 2020-09-25, Git v2.29.0-rc0 -- merge listed in batch #19) ("bisect: don't use invalid oid as rev when starting") changes the behaviour ofgit bisect
(man) to consider invalid oids as pathspecs again, as in the old shell implementation.While that behaviour may be desirable, it can also cause confusion.
For example, while bisecting in a particular repo I encountered this:$ git bisect start d93ff48803f0 v6.3 $
...which led to me sitting for a few moments, wondering why there's no printout stating the first rev to check.
It turns out that the tag was actually "6.3", not "v6.3", and thus the bisect was still silently started with only a bad rev, because
d93ff48803f0
was a valid oid and "v6.3
" was silently considered to be a pathspec.While this behaviour may be desirable, it can be confusing, especially with different repo conventions either using or not using "
v
" before release names, or when a branch name or tag is simply misspelled on the command line.In order to avoid situations like this, make it more clear what we're waiting for:
$ git bisect start d93ff4_8803f0 v6.3 status: waiting for good commit(s), bad commit known
We already have good output once the bisect process has begun in earnest, so we don't need to do anything more there.
git tag --contains A --no-contains B
命令会打印出具有该 bug 的本地标签。 - ElpieKay