Repository navigation
omarchy-dev-add-migration stamps HEAD commit time, so branches from the same commit collide on migration id #13516
Description
Problem
bin/omarchy-dev-add-migration names a new migration after HEAD's committer time:
migration_file="migrations/$(git log -1 --format=%cd --date=unix).sh"Every branch cut from the same commit therefore receives the same migration id, and the migration runner skips an id it has already recorded — so the second migration with that id silently never runs for affected accounts.
Observed collisions on id 1789095456
That timestamp is the committer time of the quattro merge commit of #11263, so branches started from it all got the same id:
- the deleted PTL-kernel migration,
- the Mise Work PATH cleanup from Remove unsafe project bin PATH injection #11336 (fix open as Give the Mise PATH cleanup a collision-free migration id #12174, renaming to
1789584463.sh), - the lock-screen fingerprint repair in Recreate lock screen fingerprint PAM file for pre-quattro setups #11322 (warned its author here).
Merging #12174 removes the conflict that currently exposes the reuse; if #11322 then merges with its current id, its repair silently won't run for accounts holding that marker. (How the PTL migration got the id was not established — possibly the same helper on a branch of that commit.)
Suggestions
- Name new migrations with the current time instead of HEAD's commit time.
- Add a merge-time check that refuses a migration id already used in the target branch's history.
Happy to implement either if that direction sounds right.
Activity
omarchybot commentedon Oct 13, 2026
Confirmed in source on
quattro(7dd477b).bin/omarchy-dev-add-migration:34names the file after HEAD's committer time, andtouchsilently reuses a file that already exists.bin/omarchy-migrate:42keys completion on the filename alone, and lines 91–95 skip any name already marked done. So two branches cut from one commit mint the same id, and whichever migration lands second never runs for anyone who completed the first.git log --all -- migrations/1789095456.shshows the reuse you describe: the PTL kernel migration was added in 8a972da, deleted in ff85faf, and the name came back as the Mise Work PATH cleanup in a73bcbf (#11336). The history doesn't show whether both ids came from this helper on the same HEAD.Two open pull requests fix the cause. Both switch to
date +%sand step past ids that are already taken:quattro, two branches from one commit got the same id, and with the PR applied they got distinct ids.noclobber), so two runs at once in one checkout can't both take the same id. It mentions this issue but doesn't close it. omabot declined to add aFixesline because that pull request is classed as a feature nobody has assigned to omabot.Neither one checks a new id against ids used earlier in the branch's history, which was your second suggestion, so a deleted migration's name could still come back by hand. The specific
1789095456collision is #12173, fixed by #12174. That is a separate item: this issue is about the helper that produces such collisions.Second opinion: Codex Medium read the same code and history and agreed on the mechanism. Its independence from this review is not guaranteed. It added that #13656 checks for an existing file and creates it as two separate steps, so two simultaneous runs in one checkout could still collide, which #13626's exclusive create prevents. It also noted that a wall-clock id from a machine with a slow clock can sort below newer migrations.
Which pull request to take is the maintainer's call, so this waits on the maintainer.