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.
git tag --contains A --no-contains B
prints the local tags that have the bug. – Directed