LEARN. PRACTICE. GROW.Define the property before searching
The laboratory in the previous lesson also creates nine commits, labelled as revisions 0 through 8 for teaching. Each stores JSON containing revision and result. Through revision 4, result is good; from 5 onward, it is bad. An oracle outside the working tree reads that file and returns an exit status. This fixture does not build an application: it demonstrates a classification contract for a constructed property. The runner executes the oracle at revisions 0 and 8 before starting the search. For a real problem, record the command, input data, dependencies and expected result that make endpoints comparable. If an external API changes behavior during the search, control that dependency or explain the uncertainty. Do not use a release date alone to declare a version good.
Read statuses without hiding environment failures
In normal mode, the oracle returns 0 for good and 1 for bad. The search identifies revision 5. In skip mode, revisions 4, 5 and 6 return 125 because the exercise makes them untestable. The result leaves candidates 4, 5, 6 and 7: the laboratory lacks enough information for a unique culprit. In the third mode, the script returns 128 to stop automation. These branches teach the distinction between a false property, an unknown property and a failure requiring a stop. A wrapper leaking status 127 from a missing tool can produce an improper bad classification; validate prerequisites before measuring regression. The Delta case calls for restoring the test environment to narrow the interval without inventing good for revisions that did not build. Keep unknown results together with their specific reason.
Save decisions and return to the starting point
The runner saves bisect log outside the repository, resets and confirms main at the original commit. It then uses replay and confirms that saved classifications reconstruct the conclusion. Replay does not automatically rerun the oracle. A historical conclusion can be repeated even after dependencies have changed, which is why the Lake case requires distinguishing reconstruction from a new measurement. Retain full IDs, test version, window and environment with the log. The oracle also sits outside the working tree so it does not disappear when bisect visits old commits. At the end of each branch, the laboratory clears bisect state and checks the branch and working tree. These checks avoid leaving the next operator at an intermediate checkout without understanding why. No reference publication is required to retain the diagnosis locally.
Turn diagnosis into an operational decision
The forty-minute guide below combines the Anchor, Cedar, Delta and Lake cases. It contains data and expected answers but has not yet been performed with participants. Allocate ten minutes to references and leases, ten to pruning, ten to the oracle and ten to handover. Deliver a reference map, a preservation list, an interval with classifications and an operational recommendation with conditions. Revision 5 is first bad in the normal fixture; this does not approve reverting a banking application. A real mitigation should consider data contracts, dependencies, consumers and change process. The laboratory executed Git 2.50.1; new options appearing in the current manual were not automatically tested. Keep gaps visible: functional compatibility, hosting, permissions, 2.56 execution and specialist review. Investigation value lies in a repeatable conclusion with precise limits.
ANCHOR / CEDAR / DELTA / LAKE GUIDE, 40 minutes
Fictional data. Do not use rewrite commands against real remotes.
0–10: O has two descendants, C and L. A reviewed O. Remote=C; A HEAD=L; origin/main=C after fetch. Write the expectation and review step.
Answer: prior decision concerned O. An explicit lease against O rejects. Review C before renewing any decision; a lease against C can accept L without including C.
10–20: B has origin/temporary, retained and local-only tag at O. temporary is deleted remotely. Compare normal fetch --prune with a proposal adding --prune-tags.
Answer: in the normal experiment, the tracking reference disappears; local branch and tag remain. Do not generalize to options/refspecs including tags. Preserve required references before authorized cleanup.
20–30: Revisions 0–4 good; 5–8 bad. First oracle returns 0/1. Second returns 125 for 4–6. Third returns 128.
Answer: first isolates 5; second leaves 4–7 as candidates; third stops automation. Do not classify unknowns as good. A missing executable can return 127 and contaminate classification.
30–40: The next shift replays the log, but the build image changed. List handover evidence and actions.
Answer: retain IDs, log, oracle version and environment; distinguish replay from a new execution; rerun relevant tests and review mitigation and data contracts. Confirm reset to main and a clean working tree.
Deliver: reference map, retention scope, classification table and recommendation with outstanding work.
Status: editorial exercise, not yet performed with participants.With the normal oracle, revision 5 is isolated. Skipping 4–6 changes the conclusion to include 4–7 and requires new evidence.
Common pitfalls
Marking environment failures as regressions; keeping the test only in a recent commit; confusing replay with execution; blaming someone without isolating the cause.
Related topics: Diagnosis and releases · Backports and dependencies · L3 handover
A useful search needs a reliable oracle, demonstrated endpoints and a report preserving remaining uncertainty.
Reference: Git bisect 2.50.0 manual · Git 2.56; workflow concepts compatible with modern Git 2.x