Is it possible to use git bisect on git tags

Question

I love using git bisect especially for solving regression bugs. However, I realized that it can also be too granular: it points out the exact commit message, what if I simply would like to know in what release did a certain bug happen (by a release I mean a git tag)?

The above need not be mutually exclusive, I can start by finding out the tag that caused the bug, then simply rerun another git bisect on that tag as well.

Answer 1

Is it possible to use git bisect on git tags

Yes, assuming you are using the correct tag name.
If not, git bisect will be clearer with Git 2.37:

"git bisect"^(man) was too silent before it is ready to start computing the actual bisection, which has been corrected with Git 2.37 (Q3 2022).

See commit f11046e, commit 0cf1def (11 May 2022) by Chris Down (cdown).
^{(Merged by Junio C Hamano -- gitster -- in commit 945b9f2, 20 May 2022)}

bisect: output state before we are ready to compute bisection

^{Signed-off-by: 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.

Answer 2

If you have a total order over a set of tags, you can just git bisect skip [range] or git bisect skip [range] [range] [range] ... — where each [range] would be tag1..tag2~1, tag2..tag3~1, … — while in a git bisect session