Is it possible to use git bisect on git tags
Asked Answered
C

2

14

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.

Callipash answered 10/1, 2019 at 8:12 Comment(2)
Why not just convert the commit hash to its corresponding tag?Ongoing
If Commit A causes the bug and it is fixed by Commit B, git tag --contains A --no-contains B prints the local tags that have the bug.Directed
A
1

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

Araby answered 4/12, 2019 at 7:47 Comment(0)
N
0

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.

Nureyev answered 22/5, 2022 at 17:2 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.