I know what git reset --hard normally does, but I saw it used in a git help bisect example and I don't understand the effect:
Avoiding testing a commit
If, in the middle of a bisect session, you know that the suggested revision is not a good
one to test (e.g. it fails to build and you know that the failure does not have anything
to do with the bug you are chasing), you can manually select a nearby commit and test that one
instead.
For example:
$ git bisect good/bad # previous round was good or bad.
Bisecting: 337 revisions left to test after this (roughly 9 steps)
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
Then compile and test the chosen revision, and afterwards
mark the revision as good or bad in the usual manner.
What does the last line of that example do? At first I thought this might be a typo and the example meant to say git *bisect* reset --hard HEAD~3, but that didn't make any more sense to me.
FWIW, I've never used or seen gitk, and git bisect visualize seems to have something to do with that command. Is that something I would have to learn before I can understand this example?
UPDATE: Based on the responses, I'm inferring that git bisect start creates a new branch and uses it puts you in a detached HEAD? Regardless, to understand that line, do I need to understand more of git bisect's implementation than is stated in the git bisect documentation; I searched for the word "branch" and "detach" and couldn't find anything relevant mentioned.
It does exactly the same thing as it normally does (when you’re in detached HEAD): discards your current working tree and moves to the specified revision.
If you (expect to) have a clean working tree, safer ways to achieve the same effect are git checkout HEAD~3 or git switch --detach HEAD~3.
git bisect reset is entirely unrelated.