Bisecting a Migration

Bisecting a Bug in BookNest's Database Migration

Bisect pointed at a two-line migration. git show with an empty format prints just its diff:

The culprit, and a fix in a new migrationShell
git show --format= f2b4106
# Add db/migrations/006-restore-price-cents.sql and a price test to test/api.test.js
git add db test && git commit -qm "Restore cents in prices: NUMERIC(8) meant whole dollars"
node ../check-price.js
git push -q
Output
diff --git a/db/migrations/004-widen-price.sql b/db/migrations/004-widen-price.sql
...
+-- Allow prices up to 999,999.99.
+ALTER TABLE books ALTER COLUMN price TYPE NUMERIC(8);
book 1 costs 14.99

In PostgreSQL 1,289 , NUMERIC(8) means NUMERIC(8,0), a scale of zero, so every price was rounded to whole dollars on insert; the comment shows that NUMERIC(8,2) was meant. The fix must not edit 004: databases that applied it have recorded it in schema_migrations and would never run it again. A new migration, 006-restore-price-cents.sql, alters the column to NUMERIC(8,2), and a test now pins book 1's price. Prices already rounded in an existing database stay rounded; restore them from a backup or the seed data (locally, docker compose down -v and a restart).

Migrations complicate bisecting: a database that ran every migration up to main does not move backward when bisect checks out an older commit. That is why check-price.js rebuilds the schema at every step. Keep each migration in its own commit, as here, so bisect can name it, and every commit buildable, so it never skips.