v1.2.19 — Removals sync as removals

Deleting a plugin or a config file on one machine now syncs as a deletion.

Removals are tracked as removals

A file or plugin you deleted here used to appear in Outgoing as an ordinary local edit — "Plugin updates · will sync" — and pressing Publish selected did nothing, reporting "Nothing to publish", because the publisher went looking for files that were no longer on disk.

A deletion is now carried as one end to end:

• The row reads "Removed here · N files · will delete" instead of claiming it will sync.
• Publishing it deletes it from the repo.
• Applying a repo-side removal uninstalls it on this machine.

Deletions are opt-in

Every removal arrives unticked. default_publish and default_apply are false for removals, so Select all never sweeps one up, and nothing is deleted on another machine unless you tick that row on purpose. Expect Outgoing to show 0 included when the only outstanding changes are deletions — that is the safety default doing its job, not a bug.

Clean divergences merge themselves

When both sides have moved but no single file was edited on both, the panel no longer parks in a diverged state waiting for a Resync — it merges. Overlapping edits still surface as per-file conflicts to pick through, and a clone with a dirty working tree now reports why the merge was skipped instead of quietly doing nothing.

Also

• A row no longer states its status twice. The backend already opens a bundle's summary with its status, so the panel's own prefix produced "Removed here · Removed here · 11 files"; the prefix is now dropped when the summary already leads with it.
• Twelve new tests cover the above, including the guards that stop a removal escaping its root and the prune stopping at it. 124 tests pass.

Upgrading

If your plugin directory is a clone, pull inside it and restart:

cd ~/.config/omarchy/plugins/gladimdim.config-sync
git pull
omarchy restart shell

Use omarchy restart shell, not omarchy refresh shell — the latter resets shell.json to Omarchy defaults.