Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

git-panic

Run git panic when your code is broken and you don't know why.

It automatically figures out exactly which recent commit broke your build — safely, with zero configuration in most projects — and shows you a clean, non-scary terminal UI instead of a wall of text.

git panic demo

What this actually does (plain English)

You've made a bunch of commits, everything was fine, and now something's broken and you're not sure which change caused it. The normal fix is git bisect — but it makes you manually mark each commit "good" or "bad" one at a time, and gives you no visual summary at the end.

git panic automates that entire process:

  1. It runs your test suite (or whatever command means "this project works")
  2. If it fails, it goes back through your recent commits one at a time, testing each one, until it finds the last one that actually passed
  3. It shows you a live, color-coded terminal dashboard of the whole process
  4. Once it finds the breaking point, it shows you exactly which files changed since then — and lets you view the full diff or roll back with one keypress

The important part: it never touches your real working directory. Every historical commit is tested inside a disposable, isolated git worktree — a second, throwaway checkout that shares your repo's history but can't affect your actual files. Your uncommitted work is never at risk, and gitpanic never runs git checkout behind your back.

Why it's useful

  • Zero setup in most projects. It auto-detects your test command by looking for pyproject.toml, package.json (with a test script), Cargo.toml, go.mod, or a Makefile. No config needed to try it.
  • Never risks your work. All historical testing happens in an isolated worktree — your working directory is untouched until you explicitly choose to roll back.
  • Actually shows you the answer, not just a diff to squint at — a plain sentence: "broken since commit X."
  • One-key actions. View the full diff, roll back safely (auto-stashing your current changes first), or branch off from the last good state — no need to remember the right git incantation mid-panic.
  • Free, open source, and has no dependency beyond Textual.

Install

git clone https://github.com/<you>/gitpanic.git
cd gitpanic
pip install -e .

Requires Python 3.11+. This installs a git-panic command — because any executable named git-<something> on your PATH is automatically usable as git <something>, so once installed you can just run:

git panic

anywhere inside a git repository.

Usage

git panic

That's it, in most projects. If your project's test command isn't auto-detected, tell it explicitly:

git panic --cmd "pytest -q tests/"

Or save it permanently so you never have to type it again — create a .gitpanic.toml in your repo root:

test_command = "pytest -q tests/"
lookback = 10

Keybindings (once the diagnosis screen is up)

Key Action
d view the full diff since the last known-good commit
r roll back to the last known-good commit (auto-stashes your current changes first — nothing is ever deleted)
b create a new branch at the last known-good commit, leaving your current state untouched
q quit

How it works

  1. detect.py figures out your test/build command by checking for common project markers, or reads an explicit override from .gitpanic.toml.
  2. bisector.py first tests your current (possibly uncommitted) state. If it's actually broken, it walks backwards through your recent commit history, testing each one inside an isolated worktree (via git_ops.py), until it finds the most recent passing commit.
  3. tui.py renders the live progress and final diagnosis using Textual — a real interactive terminal UI, not just printed text.

Development

pip install -e ".[dev]"
pytest tests/ -v

Tests spin up real temporary git repositories (with real commits, including one that deliberately breaks a test) to verify the diagnosis logic end to end — including a dedicated test that the worktree isolation never touches the real repo's files.

Roadmap / ideas

  • Binary search instead of linear walk-back, for large lookback ranges
  • Per-file suspect ranking (not just "these files changed," but "this file's change correlates most with the failure")
  • --since <date> as an alternative to a fixed commit count
  • Support for slower test suites: parallelize worktree testing across commits

Contributions and issues welcome.

License

MIT — see LICENSE.

About

Run git panic when your code is broken and you don't know why; it automatically finds which recent commit broke your build and shows you exactly what changed.

Topics

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages