Git Bisect Quiz

Review

1. What is the central purpose of `git bisect`?

   The official manual defines bisect as a binary search that narrows a history range to the commit that introduced a bug or changed a property.
2. What endpoint information does a normal regression bisect need?

   The official workflow begins with a later bad commit and an earlier good commit, then tests revisions between them.
3. What does `git bisect good` mean for the currently selected revision?

   The classification tells Git that the selected revision belongs on the good/old side of the search.
4. What should you do when the selected revision cannot be tested for a relevant reason?

   The official manual provides `git bisect skip` for revisions that cannot be tested and warns that skipping near the target can make the exact result indeterminate.
5. Which exit status makes `git bisect run` skip the current revision?

   The current official `git-bisect` manual reserves 125 for a revision that cannot be tested; it is skipped.
6. Which exit-status mapping is correct for `git bisect run`?

   That mapping is documented directly in the live official `git-bisect` manual.
7. What does `git bisect reset` normally do?

   The manual specifies `git bisect reset` as the normal cleanup operation and says it returns to the original HEAD by default.
8. What are `git bisect log` and `git bisect replay` used for?

   The official manual documents log/replay specifically for recording bisection decisions and replaying corrected ones after reset.
9. Can a bisect session use custom terms such as `broken` and `fixed`?

   The official manual supports alternate terms and says good/bad cannot be mixed with old/new in one session.
10. What is an important accuracy limitation of `git bisect`?

    The manual explicitly warns that skipping commits near the sought change can make the exact first bad commit impossible to determine; the lesson therefore treats the test classification as evidence, not magic.