Bisect and blame

Why this matters

"It worked last month" is a common report and a bad starting point. Bisect turns it into a specific commit in about ten checks, even across a thousand commits, and the searches after it answer the same question for a line of text.

Bisect

It is a binary search over history. You tell Git one commit where the problem exists and one where it does not; Git checks out the midpoint and asks; each answer halves the range.

$ git bisect start <bad> <good>

Then, at each step, git bisect good or git bisect bad. Ten steps cover a thousand commits.

Automating it

If the check can be a script that exits zero for good and non-zero for bad, Git does the whole search:

$ git bisect start HEAD HEAD~6
$ git bisect run ./check.sh

1e90067a1457fd9969319c1a97c12bedde7f7ea7 is the first bad commit

$ git bisect reset

The script can be anything: a test suite, a build, a grep for a string that should not be there. For a documentation problem it might check that a link resolves or that a page builds.

Two rules make this work:

• The script must not depend on uncommitted state, since Git checks out old commits underneath it.
• git bisect reset at the end, which returns you to the branch you started from. Forgetting it leaves you detached (lesson 12.5).

git bisect skip handles a commit that cannot be tested, for example one that does not build.

Blame

$ git blame -L 1,4 docs/faq.md

b81702c5 (You 2026-09-02 09:15:00 +0200 1) # Frequently asked questions
b81702c5 (You 2026-09-02 09:15:00 +0200 2) 
b81702c5 (You 2026-09-02 09:15:00 +0200 3) ## Is Trailguide free?
b81702c5 (You 2026-09-02 09:15:00 +0200 4) 

-L 1,4 limits it to a range of lines, which is what makes blame usable on a long file. Two options matter beyond that:

Blame's weakness is that it reports the last commit to touch a line, which is often a reformatting or a rename. -w and -C are how you see past that, and the platform's blame views have an "ignore this commit" control for the same reason (lesson 10.4).

Two searches that beat blame

When did this string appear or disappear?

$ git log --oneline -S 'BROKEN' -- data/trails.csv

1e90067 data: add row 4

-S finds commits that changed the number of occurrences of a string: exactly the question "who added this?". -G takes a regular expression and finds commits whose diff matches it.

How did these lines get like this?

$ git log -L 1,3:docs/faq.md

That prints the history of those specific lines, with each diff that touched them, following the range as it moves. It is slower than blame and answers a better question, because it shows the sequence rather than only the last step.

Choosing

How to do it

$ git bisect start <bad> <good>
$ git bisect run ./check.sh
$ git bisect reset
$ git blame -w -C -L 20,40 <file>
$ git log -S '<string>' -- <path>
$ git log -L 20,40:<file>

Common mistakes

• Forgetting git bisect reset, leaving the repository detached.
• A bisect script that depends on uncommitted files.
• Trusting blame's last-toucher when a reformatting commit sits on top. Use -w and -C.
• Blaming a whole file rather than a line range, and drowning.
• Using blame to answer "who added this string?" when log -S answers it directly.