I ran git reset and Pgcli froze.
It wasn’t magic. It was a trap I built myself—by forgetting how Git and Pgcli handle state when the past changes under their feet. The fix is simple once you see it. But first, know why it happens.
When you run git reset in a repo that holds migration files, seed data, or scripts that Pgcli depends on, you’re rewinding history. Pgcli doesn’t care about Git, but it does care about files and database state. If the SQL you think exists is gone—or worse, has changed—your session will hold ghosts. Pgcli’s tab-completion will suggest commands that no longer work. Queries will fail.
Here’s the clean way out:
- Kill the Pgcli session.
git reset --hard to the commit you need.- Run migrations from scratch.
- Restart Pgcli and reconnect.
If you need to keep uncommitted database changes, stash them in your database with a dump file. Keep migrations idempotent so reruns aren’t painful. And remember that Pgcli auto-completes against your current schema—it will always serve stale suggestions after a reset unless you refresh it.
For teams, the problem spreads faster. One person rolls back, another pulls, Pgcli shows mismatched tables, nobody can trust their shell. Solve it with workflow rules: always reset with a clean database snapshot, pair resets with migrations, and never run Pgcli against a changing schema in active development without clearing sessions.
This combo—git reset and Pgcli—can be reliable. Treat them like linked gears, not separate tools. Build scripts that handle both: one command to reset code, wipe and rebuild the database, and restart Pgcli. Remember, speed here is not just convenience—it’s less downtime, fewer surprises, and no schema drift.
If you want to see a setup where these resets and database interactions happen in minutes, with Pgcli ready to run right after switching commits, check out hoop.dev. Spin it up, connect your repo, and watch the reset-to-query cycle drop to seconds. The difference is real.