Preference sharing: a manual first slice of the dots plan

[jordanhubbard]

I use several Omarchy machines and want to share preferences without copying hardware configuration or making my home directory a Git worktree.

I have separated preference sharing from session restoration and file backup. PR #12037 is a concrete first slice of plans/dots.md: an audited shared/local manifest, a private bare repository, local recovery history, and explicit publish/pull through Setup > Preferences and System > Preferences. Automatic timer snapshots and update hooks are deferred.

There is one design choice on which I would especially appreciate maintainer direction: the plan describes a remote-wins fallback for conflicting changes. This implementation keeps a persistent pending update and asks the user to choose between this machine and the shared version before continuing. It preserves both sides and refuses to overwrite edits made during review, at the cost of another interaction.

Would you prefer that explicit conflict choice for the first version, or the plan's remote-wins behavior with the local version preserved in recovery history? The PR includes real two-machine Git tests and screenshots from the exercised conflict picker, so the behavior is reviewable.

The separate session PR #10353 is now opt-in and limited to supported applications and numbered workspaces. For backups, I am building on #7814 and contributing recovery/setup fixes to its author's branch instead of proposing another backend. The integrated preview remains available in my fork.

[jdx]

Hi @jordanhubbard — I'm the author of mise, which Omarchy already ships. In case you haven't seen #11029: most of plans/dots.md already exists in mise as mise dot. It tracks files in place with a local Git history, saves edits in the background, records labeled before/after snapshots around a command such as omarchy-migrate, and supports rollback and undo. It also syncs to a private remote, with optional age encryption for individual files. It has shipped since 2026.9.2, and mise users already rely on it day to day.

On your conflict question, mise made the same choice you did. A pull records a decision for each conflicting file (--keep-local or --take-remote), applies nothing until every conflict is resolved, and can itself be undone.

The main piece missing was the plan's local tier, which caused your input.lua problem. I'm adding machine-local tracking to mise now, and then I'll open an Omarchy PR that builds dots on top of it. Rather than Omarchy maintaining two sync engines, I'd like to combine our work: your manifest and menu flow on top of mise's history and sync. Would you be up for that?

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: 2.1.289.