能否在Git标签上使用Git bisect？

Question

我喜欢使用 git bisect 特别是用于解决 回归错误。但是，我意识到它有时过于细粒度: 它指出了确切的提交消息，如果我只想知道某个 bug 是在哪个版本（即 Git 标签）中发生的怎么办？

以上并不必互相排斥，我可以先找出引起该 bug 的标签，然后在该标签上重新运行另一个 git bisect。

- abbood

---

为什么不将提交哈希转换为其对应的标签？ - Tim Biegeleisen

如果提交 A 导致了 bug，并且由提交 B 修复，那么 git tag --contains A --no-contains B 命令会打印出具有该 bug 的本地标签。 - ElpieKay

Answer 1

如果您有一组标签的总订单，您可以在 git bisect 会话中只需使用 git bisect skip [range] 或 git bisect skip [range] [range] [range] ... — 其中每个 [range] 将是 tag1..tag2~1、tag2..tag3~1 等等。

- Mika Feiler

Answer 2

能否在 Git 标签上使用 git bisect？

是的，假设您使用了正确的标签名称。如果没有，请注意，在 Git 2.37 中，git bisect 将更加清晰：

"git bisect"^(man) 在准备开始计算实际二分时过于沉默，这已在 Git 2.37（2022 年第三季度）中得到了纠正。

查看 提交 f11046e，提交 0cf1def（2022年5月11日），由 Chris Down (cdown） 提交。
^{（已合并于 提交 945b9f2 中，由 Junio C Hamano -- 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 of git 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.

- VonC