Skip to content

Fix detection of "new migrations" in omarchy-update #219

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

rmacklin
Copy link

@rmacklin rmacklin commented Jul 18, 2025

Previously, omarchy-update used the timestamp of the most recent git commit to determine which migrations are "new" and should be executed.

Unfortunately, that strategy can (and did: #187) fail in certain scenarios. If a migration was generated at time T1 but not merged until time T3, and meanwhile omarchy's master branch was updated to a new release with commit timestamp T2 (where T1 < T2 < T3), then anyone who runs omarchy-update between T2 and T3 would end up with last_updated_at equal to T2; thus, on their next omarchy-update it would fail to detect the migration with timestamp T1 as a "new" migration that should be executed.

This PR changes the strategy for detecting "new" migrations to avoid that problem. Rather than recording the most recent commit's timestamp, we record its SHA. Then, after pulling the new changes, we can leverage

git diff --name-only --diff-filter=A $SHA.. migrations/*.sh

to return precisely the list of migration files that were introduced by our git pull. It doesn't matter if any of those migrations have a timestamp that was earlier than the timestamp of the commit we started on - we will always execute every migration that didn't exist before our git pull!

Previously, `omarchy-update` used the timestamp of the most recent git
commit to determine which migrations are "new" and should be executed.

Unfortunately, that strategy can (and did) fail in certain scenarios. If
a migration was generated at time T1 but not merged until time T3, and
meanwhile omarchy's `master` branch was updated to a new release with
commit timestamp T2 (where T1 < T2 < T3), then anyone who runs
`omarchy-update` between T2 and T3 would end up with `last_updated_at`
equal to T2; thus, on their next `omarchy-update` it would fail to
detect the migration with timestamp T1 as a "new" migration that should
be executed.

This commit changes the strategy for detecting "new" migrations to avoid
that problem. Rather than recording the most recent commit's timestamp,
we record its SHA. Then, after pulling the new changes, we can leverage
`git diff --name-only --diff-filter=A $SHA.. migrations/*.sh`
to return precisely the list of migration files that were introduced by
our `git pull`. It doesn't matter if any of those migrations have a
timestamp that was earlier than the timestamp of the commit we started
on - we will always execute *every* migration that didn't exist before
our `git pull`!
@dhh dhh changed the base branch from master to dev July 20, 2025 22:55
@dhh dhh merged commit f81983e into basecamp:dev Jul 20, 2025
@dhh dhh mentioned this pull request Jul 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants