{"slug": "git-bisect", "name": "git bisect", "category": "git", "category_name": "Git and code hosting", "description": "", "recommenders": 5, "commenters": 7, "warners": 1, "score": 3.457, "rising": -1.64, "first": "2025-11-02", "latest": "2026-07-14", "why": "I used git bisect in anger for the first time recently and it felt like magic.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 1, "compare": 0, "warn": 1}, "spark": [4, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "I used git bisect in anger for the first time recently and it felt like magic.", "kind": "", "icon": true, "domain": "speechcode.com", "github_repo": null, "official_url": "https://git-scm.com/docs/git-bisect", "pricing": "", "aliases": ["git bisect"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 760929040, "item_id": 47558065, "url": "https://news.ycombinator.com/item?id=47558065", "by": "hauntsaninja", "date": "2026-03-28", "version": null, "stance": "recommend", "quote": "git bisect works great for tracking down regressions", "excerpt": "git bisect works great for tracking down regressions, but relies on the bug presenting deterministically. But what if the bug is non-deterministic? Or worse, your behaviour was always non-deterministic, but something has changed, e.g. your tests went from somewhat flaky to very flaky. In addition to the repo linked in the title, I also wrote up a little bit of the math behind it here: https://hauntsaninja.github.io/g", "context": "", "use_case": "finding regression commits", "switched_from": "", "story": "Show HN: Git bayesect \u2013 Bayesian Git bisection for non-deterministic bugs"}, {"id": 732733872, "item_id": 45795867, "url": "https://news.ycombinator.com/item?id=45795867", "by": "aag", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "Make sure you know about exit code 125 to your test script.", "excerpt": "Make sure you know about exit code 125 to your test script. You can use it in those terrible cases where the test can't tell, one way or another, whether the failure you seek happened, for example when there is an unrelated build problem. I wrote a short post on this: https://speechcode.com/blog/git-bisect", "context": "", "use_case": "Finding regressions", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732719728, "item_id": 45794983, "url": "https://news.ycombinator.com/item?id=45794983", "by": "tarwich", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "Sometimes git bisect is really nice to have.", "excerpt": "When I learned about git bisect I thought it was a little uppity. I thought it was something I would never use in a practical scenario. Working on large code bases. However, sometimes a bug pops up and we don't know when it started. We use git bisect not place blame on a person, but to try to figure out when the bug was no longer there so we know what code introduced it. Yes, clean code helps. Sometimes git bisect is", "context": "works on large code bases", "use_case": "finding bug-introducing commits", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732709168, "item_id": 45794323, "url": "https://news.ycombinator.com/item?id=45794323", "by": "funnymunny", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "I used git bisect in anger for the first time recently and it felt like magic.", "excerpt": "I used git bisect in anger for the first time recently and it felt like magic. Background: We had two functions in the codebase with identical names and nearly identical implementations, the latter having a subtle bug. Somehow both were imported into a particular python script, but the correct one had always overshadowed the incorrect one - that is, until an unrelated effort to apply code formatting standards to the ", "context": "", "use_case": "finding bug-introducing commit", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732692992, "item_id": 45793312, "url": "https://news.ycombinator.com/item?id=45793312", "by": "paulbjensen", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "I would say git bisect was a lifesaver", "excerpt": "I recently used git bisect to help find the root cause of a bug in a fun little jam of mine (a music player/recorder written in Svelte - https://lets-make-sweet-music.com). My scenario with the project was: - no unit/E2E tests - no error occurring, either from Sentry tracking or in the developer tools console. - Many git commits to check through as GitHub's dependabot alerts had been busy in the meantime. I would say", "context": "", "use_case": "Finding regressions", "switched_from": "", "story": "At the end you use `git bisect`"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 761717633, "item_id": 47607352, "url": "https://news.ycombinator.com/item?id=47607352", "by": "rs545837", "date": "2026-04-01", "version": null, "stance": "warn", "quote": "bisect drops to ~44% accuracy while bayesect holds at ~96%", "excerpt": "Really fun work, and the writeup on the math is great. The Beta-Bernoulli conjugacy trick making the marginal likelihood closed-form is elegant. We ran benchmarks comparing bisect vs bayesect across flakiness levels. At 90/10, bisect drops to ~44% accuracy while bayesect holds at ~96%. At 70/30 it's 9% vs 67%. The entropy-minimization selection is key here since naive median splitting converges much slower. One thing", "context": "", "use_case": "Finding regressing commits", "switched_from": "", "story": "Show HN: Git bayesect \u2013 Bayesian Git bisection for non-deterministic bugs"}]}], "who": [{"by": "tarwich", "context": "works on large code bases", "url": "https://news.ycombinator.com/item?id=45794983", "date": "2025-11-02"}], "tags": [], "use_cases": ["finding regressions", "finding bugs", "finding regressing commits", "finding regression commits", "finding bug-introducing commits", "finding bug-introducing commit"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=45791882", "title": "At the end you use `git bisect`", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=47557921", "title": "Show HN: Git bayesect \u2013 Bayesian Git bisection for non-deterministic bugs", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48901010", "title": "The Git history command deserves more attention", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 4}, "2025-12": {}, "2026-01": {}, "2026-02": {}, "2026-03": {"recommend": 1}, "2026-04": {"warn": 1}, "2026-05": {}, "2026-06": {}, "2026-07": {"neutral": 1}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 782452912, "item_id": 48903307, "url": "https://news.ycombinator.com/item?id=48903307", "by": "user43928", "date": "2026-07-14", "version": null, "stance": "neutral", "quote": "I used git bisect once in 10 years", "excerpt": "I used git bisect once in 10 years, and it was when I learned about its existence. I am convinced that very few know about git bisect, much less use it regularly.", "context": "", "use_case": "finding bugs", "switched_from": "", "story": "The Git history command deserves more attention"}, {"id": 761717633, "item_id": 47607352, "url": "https://news.ycombinator.com/item?id=47607352", "by": "rs545837", "date": "2026-04-01", "version": null, "stance": "warn", "quote": "bisect drops to ~44% accuracy while bayesect holds at ~96%", "excerpt": "Really fun work, and the writeup on the math is great. The Beta-Bernoulli conjugacy trick making the marginal likelihood closed-form is elegant. We ran benchmarks comparing bisect vs bayesect across flakiness levels. At 90/10, bisect drops to ~44% accuracy while bayesect holds at ~96%. At 70/30 it's 9% vs 67%. The entropy-minimization selection is key here since naive median splitting converges much slower. One thing", "context": "", "use_case": "Finding regressing commits", "switched_from": "", "story": "Show HN: Git bayesect \u2013 Bayesian Git bisection for non-deterministic bugs"}, {"id": 760929040, "item_id": 47558065, "url": "https://news.ycombinator.com/item?id=47558065", "by": "hauntsaninja", "date": "2026-03-28", "version": null, "stance": "recommend", "quote": "git bisect works great for tracking down regressions", "excerpt": "git bisect works great for tracking down regressions, but relies on the bug presenting deterministically. But what if the bug is non-deterministic? Or worse, your behaviour was always non-deterministic, but something has changed, e.g. your tests went from somewhat flaky to very flaky. In addition to the repo linked in the title, I also wrote up a little bit of the math behind it here: https://hauntsaninja.github.io/g", "context": "", "use_case": "finding regression commits", "switched_from": "", "story": "Show HN: Git bayesect \u2013 Bayesian Git bisection for non-deterministic bugs"}, {"id": 732733872, "item_id": 45795867, "url": "https://news.ycombinator.com/item?id=45795867", "by": "aag", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "Make sure you know about exit code 125 to your test script.", "excerpt": "Make sure you know about exit code 125 to your test script. You can use it in those terrible cases where the test can't tell, one way or another, whether the failure you seek happened, for example when there is an unrelated build problem. I wrote a short post on this: https://speechcode.com/blog/git-bisect", "context": "", "use_case": "Finding regressions", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732719728, "item_id": 45794983, "url": "https://news.ycombinator.com/item?id=45794983", "by": "tarwich", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "Sometimes git bisect is really nice to have.", "excerpt": "When I learned about git bisect I thought it was a little uppity. I thought it was something I would never use in a practical scenario. Working on large code bases. However, sometimes a bug pops up and we don't know when it started. We use git bisect not place blame on a person, but to try to figure out when the bug was no longer there so we know what code introduced it. Yes, clean code helps. Sometimes git bisect is", "context": "works on large code bases", "use_case": "finding bug-introducing commits", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732709168, "item_id": 45794323, "url": "https://news.ycombinator.com/item?id=45794323", "by": "funnymunny", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "I used git bisect in anger for the first time recently and it felt like magic.", "excerpt": "I used git bisect in anger for the first time recently and it felt like magic. Background: We had two functions in the codebase with identical names and nearly identical implementations, the latter having a subtle bug. Somehow both were imported into a particular python script, but the correct one had always overshadowed the incorrect one - that is, until an unrelated effort to apply code formatting standards to the ", "context": "", "use_case": "finding bug-introducing commit", "switched_from": "", "story": "At the end you use `git bisect`"}, {"id": 732692992, "item_id": 45793312, "url": "https://news.ycombinator.com/item?id=45793312", "by": "paulbjensen", "date": "2025-11-02", "version": null, "stance": "recommend", "quote": "I would say git bisect was a lifesaver", "excerpt": "I recently used git bisect to help find the root cause of a bug in a fun little jam of mine (a music player/recorder written in Svelte - https://lets-make-sweet-music.com). My scenario with the project was: - no unit/E2E tests - no error occurring, either from Sentry tracking or in the developer tools console. - Many git commits to check through as GitHub's dependabot alerts had been busy in the meantime. I would say", "context": "", "use_case": "Finding regressions", "switched_from": "", "story": "At the end you use `git bisect`"}]}