Updating

./setup update pulls the repository and installs again.

./setup update

It runs git pull --autostash --ff-only, says which version it moved from and to, then everything install does, with the same flags: ./setup update --skip-packages skips the packages on the way through. The install runs from the setup just pulled, so a release that changes the installer takes effect on the same update. A checkout with no upstream branch skips the pull and installs what is there. When a release adds packages, they are installed with a full system upgrade in the same step (pacman -Syu --needed), as Arch expects.

An update stops before copying anything when the pull leaves conflicts, which happens when you edited the repository itself and the release changed the same lines. Your edits are in the stash: resolve the conflicts (git status lists them), run git stash drop, and update again.

The extras install set up once are left alone, so what you changed in those programs stays. One that was skipped is tried again, and Spotify is patched again after a Spotify update has taken the palette away.

Releases and branches

main only moves when a version is released. A clone made from the README is on main, so ./setup update brings the latest release and nothing in between. Work in progress lives on dev: git switch dev in your clone follows it, half-finished work included, and git switch main goes back. Every release is a tag, v0.1.0 and on, with its notes under Releases.

The version you have is under Settings → System → This machine, beside the processor, the memory and the uptime: the release, such as v0.3.0, with the branch under it. Between releases the line under it adds the commits since that release and a short hash, and says edited when the checkout has changes of its own.

From Settings

Settings → System → Updates is for impasto itself, not the packages it runs.

• Check for updates asks the remote of the checkout impasto was installed from what has landed since: when the page opens, at most every half hour, and whenever you press Check. It reads Up to date with the time it checked, or how many commits are waiting, counted from the version that was installed, so an update whose install stopped half-way still offers Update.
• What is waiting lists those commits, newest first: up to twelve, then +N more.
• Update appears only when something is waiting, and reads To and the version it would leave you on. It runs setup update in a floating terminal, where its questions and your password stay visible. It is locked, with Commits of your own are not on the remote, when your clone has commits the remote does not, since the pull only fast-forwards.

Updates, with commits waiting.

Two copies: yours and the repository’s

Every configuration file exists twice, once in the repository and once where it is used. The desk reads the copy, never the repository.

Edit your copy — ~/.config/hypr/modules/look.lua, say — and the change applies at once. setup notices it has been edited and leaves it alone. When the repository later changes that file, the repository’s version is written beside yours as <name>.new and yours stays in place.

Settings → System → Updates → Changed files lists them: every installed file you have edited or deleted, with a button for each. A deleted one has Restore; an edited one has Reset, which puts impasto’s version back and keeps yours in the backups, or, when a newer version is waiting beside it, Keep mine and Use the new one. Deleted wallpapers are gathered by folder, so forty of them are one line. ./setup files does the same from a terminal.

Or settle a .new file by hand — compare the two and keep one:

diff ~/.config/hypr/modules/look.lua ~/.config/hypr/modules/look.lua.new
mv ~/.config/hypr/modules/look.lua.new ~/.config/hypr/modules/look.lua   # take the repository's
rm ~/.config/hypr/modules/look.lua.new                                   # or keep yours

Either choice is permanent. If you take the repository’s version, the file is unedited again and updates normally. If you keep yours, no .new appears again until the repository changes that file again.

Edit the repository and nothing happens until you copy it:

./setup sync            # copy home/ into $HOME once
./setup sync --watch    # copy again on every save, until Ctrl+C

A sync that changes the shell’s files ends by asking the running shell to reload, once the last file has landed, so the desk never runs half of a change. --watch needs inotify-tools.

Note

sync only covers home/. A change under system/, such as the login screen’s theme, needs ./setup system, which asks for a password.

How setup copies

Each copy is written atomically, next to its destination and then renamed, so the shell never reads half a file. The hash of every file is kept in a manifest, ~/.local/state/impasto/home.manifest (and system.manifest for /). On every run it decides file by file:

What it finds	What it does
Nothing at the path, never written	Writes the file.
The file it wrote, deleted since	Leaves it deleted (the wallpapers you do not want, say) and says how many it left out. --restore puts them back.
A different file, the first time	Moves it to ~/.local/state/impasto/backups/<timestamp>/, then writes. A link in the way is moved there too.
The file it wrote, unedited	Replaces it with the repository’s version.
The file it wrote, edited since	Keeps yours, and writes the repository’s beside it as <name>.new.
A file gone from the repository	Deletes it if unedited. If you edited it, it stays, and setup says so.
A file it never wrote	Never touches it.

The last row matters. The palette writes themes into ~/.config/btop, cava, yazi, gtk-3.0 and elsewhere, and the shell keeps its settings in ~/.local/state/quickshell/. None of those were written by setup, so none of them are ever overwritten, deleted or backed up.

Under /, what was in the way is copied to the backups rather than moved, because the backups directory belongs to you.

Uninstalling

./setup uninstall

It removes every file it installed that has not been edited since, from both $HOME and /. An edited file is left in place and named. Then it puts back what the install moved aside, oldest backup first, wherever the path is free again. Anything that cannot go back because the path is taken stays in ~/.local/state/impasto/backups/, and setup says how many. The record of which extras have run goes too, so a later install sets them up again. The virtual camera’s module options are removed, and the boot splash goes back to Plymouth’s default theme, with the initramfs rebuilt.

What stays behind:

• the packages, oh-my-zsh and the Hyprland plugins;
• the shell’s settings, notes, tasks and the rest of ~/.local/state/quickshell/;
• the themes the palette wrote, and the impasto icon theme;
• what the extras set: the default applications, dark GTK, Nautilus’s and VSCodium’s settings, VSCodium’s extensions, Vesktop’s tick, Spotify’s patch, and the packages and models camera effects installed;
• howdy-next and the face enrolled with it (the lock’s PAM service goes with the rest of /);
• sddm, still enabled, if install enabled it;
• /var/lib/impasto/faces, because what is in it is somebody’s photograph.

Caution

The login screen’s theme is removed with the rest, and so is 10-impasto.conf, which names it: SDDM comes up in its own theme at the next boot. If a file of yours sets Current=impasto, point it at another theme before uninstalling.

Add --dry-run to see the list first. Every verb is in The setup script.