When a failure used to work, history is a search space. Start by reproducing the current failure and identifying a revision where the same test passes. git log, git show <revision>:<path> and focused diffs help connect behavior with changes. git blame identifies the commit associated with lines, but the last line editor is not necessarily the author of the underlying defect.
Build a useful predicate
Bisect asks whether a selected revision is good or bad with respect to one specific property. The test must measure that property consistently and isolate unrelated environmental failures. For a simple linear history with one good-to-bad transition, testing a midpoint repeatedly cuts the candidate range, needing roughly logarithmic classifications. Merge graphs, skipped revisions and non-monotonic behavior complicate that model; do not promise every repository has one clean numerical boundary.
git bisect start broken known-good
git bisect run ./test.sh
git bisect log
git show --stat refs/bisect/badThe bad endpoint comes first in bisect start. In a manual run, execute the test at the checked-out revision and then classify with git bisect good or git bisect bad. Do not infer good or bad from whether Git checked the commit out successfully. That only establishes checkout success, not program behavior.
Automate without corrupting the evidence
With bisect run, exit zero means good; nonzero values from 1 through 127 mean bad, except 125, which skips an untestable revision. Other values can abort the automated search. A script returning a shell "command not found" status may therefore falsely classify a commit as bad unless you distinguish infrastructure failure. Preserve a deterministic environment and make the test build the selected revision's code rather than reusing an unrelated binary.
These labs provide an executable test.sh that checks feature.txt for the passing state. Only that supplied script is supported with bisect run. It is a deliberately small behavioral predicate, not a simulation of the bisect algorithm: the installed Git performs the actual search. Fixtures vary the first failing checkpoint so a guessed fixed revision does not substitute for diagnosis.
Inspect, then leave the search
At completion Git reports the first bad commit consistent with the classifications. HEAD can still be at the last tested good revision; it does not always check out the reported bad commit. Inspect the reported ID or refs/bisect/bad, confirm the transition and inspect its patch. Outside this task, git bisect reset returns from the search to its starting checkout; this lab asks you to leave the completed state in place for grading first. Search navigation normally detaches HEAD and should not rewrite main.
If a commit cannot be tested, skip it rather than inventing a result; too many skipped candidates may prevent a unique answer. If the predicate was wrong, inspect the bisect log, reset and restart with corrected evidence. The most valuable result is a reproducible explanation of the transition, not merely a hash to blame.