At the end you use `git bisect`

Original Article ↗ Hacker News Discussion ↗

Role of git bisect vs tests/CI

  • Some argue heavy use of bisect signals process problems: poor test coverage, brittle or missing CI, over-complex architecture.
  • Many push back: tests only show presence, not absence, of bugs; security holes, race conditions, and subtle regressions routinely slip through.
  • Common recommended workflow: reproduce bug → write a regression test/script → run git bisect with the new test → then keep the test.
  • Consensus: bisect does not compete with tests; it complements them when something escaped.

When git bisect shines

  • Large, poorly understood or legacy “big ball of mud” codebases where reasoning locally is hard.
  • Unknown or third‑party projects, or when original authors are gone.
  • Kernel/OS and hardware-specific bugs, where only the end user can reproduce the issue.
  • “Is this a bug or a feature?” and “how long has this been broken?” investigations, especially with data correction or compliance implications.
  • Flaky tests or race conditions where you need to run a test many times per commit and let bisect automate it.
  • Situations with no prior tests or obvious errors (silent data corruption, logic changes).

Limitations and pitfalls of bisect

  • Requires a mostly-linear, buildable history; broken intermediate commits or massive kitchen‑sink changes degrade its value.
  • Fails when a bug is introduced in one commit but only manifests (or is masked/unmasked) much later or intermittently.
  • Sometimes identifying the bad commit is the easy part; understanding the change can require further “bisect” within that commit or more elaborate techniques.

Commit history strategy and bisect

  • Large subthread debates squash-vs-merge-vs-rebase:
    • Squash-merge fans value a clean, PR-level history and simpler CI assumptions.
    • Opponents say squashing throws away useful diagnostic history and makes archaeology harder; prefer merge commits with --no-ff and tools like git log/bisect --first-parent.
    • Some consider well-structured, semantic commits “basic engineering hygiene”; others see rebase/squash workflows as unnecessary bureaucracy.
  • There’s agreement that disciplined, human-readable commits make bisect and maintenance substantially more effective.

Other git tools and technical details

  • People frequently combine bisect with git log -L, git log -S, and git blame to narrow down functions or strings.
  • Tips include: keeping new regression tests uncommitted (or in ignored .bisect dirs), using exit code 125 to skip untestable commits, and handling API/signature changes with small compatibility shims.
  • Discussion notes that binary search is conceptually simple but tricky to implement correctly; most recommend using library implementations rather than rolling your own.