A build had started taking almost twice as long as it used to, sometime in the last few weeks, and I had no idea when. I spent several evenings guessing — reverting a dependency bump, then a config change, then reverting the revert when neither helped — before I remembered that git bisect exists specifically so I don’t have to guess.
Letting the tool do the work
git bisect start, mark the current commit bad, mark a commit from six weeks ago good, and let it walk the binary search for me instead of my memory:
git bisect start
git bisect bad HEAD
git bisect good HEAD~80
git bisect run npm run build -- --timing
Four steps in, it landed on the actual culprit: a content collection glob pattern I’d widened months earlier to catch some edge-case file naming, which was now also matching a folder of draft posts I kept locally but never committed — except I had committed them once, briefly, before marking them draft, and the glob was still touching their history on every incremental build.
Why I hadn’t just done this sooner
Bisecting felt like overkill for what I assumed was a small config issue, so I reached for manual guessing first, which took four evenings to get nowhere. The actual bisect took four minutes once I started it. The lesson isn’t really about git — it’s that “this feels too simple a tool for my complicated-feeling problem” is a bad reason to skip the simple tool.