coja/dots
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Update] bulk update

Browse Source
This commit is contained in:
coja
2026-09-17 20:45:06 +02:00
committed by Coja
parent 3ec2503f38
commit ed7e34552d
158 changed files with 3258 additions and 2419 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+47 -13
View File
@@ -33,8 +33,28 @@ a host override a single file in a shared dir without shadowing the rest.
**Editing a config edits the repo copy directly** (it's a symlink) — no deploy step. You only re-run
`install.sh` when files are **added or removed** (to create/prune symlinks). See **Syncing** below.
The repo must be cloned to **`~/.dots`** (the relative `../.dots` symlink convention). A host's
package name must match `hostname -s` (or pass the host explicitly, e.g. `./install.sh lw`).
The repo must be cloned to **`~/.dots`** (the relative `../.dots` symlink convention).
### Which host package a machine deploys
**Hostname is not the authority** — the machine remembers its own choice, so several boxes can deploy
the same overlay without sharing a hostname. `install.sh` resolves the host as:
1. the explicit argument (`./install.sh wm`),
2. else the name in **`~/.config/dots-host`** — written by `install.sh` itself on every run that
resolved a real package, so a one-time `./install.sh <host>` is all the setup there is,
3. else `hostname -s`, purely as a convenience guess for boxes where the two happen to agree.
`~/.config/dots-host` is a machine-local, hand-editable one-word file — the sibling of the
`dots-headless` marker above. It is what makes **`bin/dotsync` correct**: dotsync re-links
automatically and has no argument to pass, so without a recorded host it could only guess. Switching
a machine to another overlay is just `./install.sh <other>` — the previously recorded host is
unstowed first, so the base layers don't collide with its leftover links.
Mismatched hostnames used to fail in a way worth recognizing: `./install.sh` on a box whose hostname
matches no package deploys `common`, aborts `gui` on every file the real overlay owns
(`existing target is stowed to a different package`) and skips the overlay entirely — a loud
`exit 1`, but a half-applied one, where newly added files silently get no symlink.
## Install (new machine)
@@ -42,7 +62,7 @@ package name must match `hostname -s` (or pass the host explicitly, e.g. `./inst
sudo pacman -S stow
git clone <remote> ~/.dots
cd ~/.dots
./install.sh # auto-detects host via `hostname -s`
./install.sh wm # name the host package once — it is remembered (see above)
```
`./install.sh -h` lists all options: `-n` dry-run, `-a` adopt (first run), `-D` unstow (revert),
@@ -89,15 +109,16 @@ Because configs are symlinks into the repo, **you almost never run `install.sh`
- **Never `stow` the repo root** (`stow .dots`, `stow */`) — it folds package dirs into `~` as stray
`~/common`, `~/gui`, … symlinks. `install.sh` only ever links package *contents*.
- **New host:** create a top-level `<name>/` package (at least a `host.fish`), commit, then
`./install.sh`. If it's terminal-only, skip the package and just `touch ~/.config/dots-headless`
(it runs `common` only).
`./install.sh <name>` (naming it once records it — later runs and dotsync need no argument).
If it's terminal-only, skip the package and just `touch ~/.config/dots-headless` (it runs
`common` only).
## Tooling (`bin/`)
| Command | What it does |
|---|---|
| `./install.sh [host]` | Deploy `common → gui → <host>`. Flags: `-n` dry-run, `-a` adopt (first run), `-D`/`--unstow` revert (remove this host's symlinks; repo + real files kept), `-h` help. Self-heals: headless hosts get any stray `gui` unstowed; fails loudly (exit 1) if a package couldn't stow. |
| `./bin/dotsync [-n]` | Sync with least churn: `git pull`, re-stow only if files were added/removed. |
| `./install.sh [host]` | Deploy `common → gui → <host>`. Host = arg, else `~/.config/dots-host`, else `hostname -s`; the resolved host is recorded there. Flags: `-n` dry-run, `-a` adopt (first run), `-D`/`--unstow` revert (remove this host's symlinks; repo + real files kept), `-h` help. Self-heals: headless hosts get any stray `gui` unstowed, a previously recorded host is released before re-deploying; fails loudly (exit 1) if a package couldn't stow. |
| `./bin/dotsync [-n\|host]` | Sync with least churn: `git pull`, re-stow only if files were added/removed (via `install.sh`, using the recorded host). |
| `./bin/reconcile-hyde.sh [-i\|--relink] [host]` | After a HyDE update overwrote `~/.config/hypr`, reconcile HyDE's new files against your dots versions (report / `-i` keep·take·merge each / `--relink` re-symlink). |
## How per-host differences are expressed
@@ -118,9 +139,16 @@ provider also listed so any host can switch) — no per-host overrides.
The Hyprland config is [HyDE](https://github.com/HyDE-Project/HyDE)-based. `gui/.config/hypr/*` is
your customization layer, but it **sources HyDE's framework**:
`source = ~/.local/share/hyde/hyprland.conf` — which defines `$mainMod` and other variables and is
**not tracked by dots** (HyDE generates it). So a GUI host must have **HyDE installed**, or Hyprland
fails to start (`source globbing error` + `invalid mod $mainMod`).
`source = ~/.local/share/hyde/hyprland.conf` — which defines `$mainMod` and other variables. So a GUI
host must have **HyDE installed**, or Hyprland fails to start (`source globbing error` +
`invalid mod $mainMod`).
That file used to be generated-and-untracked, but **HyDE 26.x deploys neither it nor `hyde.conf`**,
so since the 2026-08-14 audit both are **tracked pins** in `gui/.local/share/hyde/` — the one
deliberate exception to the generated-files-are-never-tracked rule below, interim until the Lua port.
After pulling that audit, a machine must run **`./bin/hyde-materialize.sh` before `./install.sh`**:
the newly-untracked files leave dangling stow symlinks otherwise, and hypr/hyprlock treat a missing
`source =` as a hard parse error.
- Install/update HyDE with its own installer (`~/HyDE/Scripts/install.sh`); it also pulls the
required apps (`xdg-desktop-portal-hyprland`, `xdg-desktop-portal-gtk`, `hyprpolkitagent`).
@@ -143,9 +171,15 @@ track neither. HyDE-managed customization goes via:
self-contained two-bar config launched raw (`waybar -c …custom.jsonc -s …custom.css` — exec-once,
the Ctrl+Alt+W / Super+Shift+R binds, and the `wbar` abbr). **Never route it through
`hyde-shell waybar --set`** — waybar.py would clobber the repo's files as above. HyDE only reads
from `layouts/`, which is what makes them safe to track. On a rig host, HyDE's own bar (systemd
user unit `hyde-<XDG_SESSION_DESKTOP>-bar.service`, auto-restarting) must be disabled once:
`systemctl --user stop <unit>; systemctl --user mask <unit>`.
from `layouts/`, which is what makes them safe to track. On a rig host, HyDE's own bar must be
disabled once, or **two bars appear at every login** — and the launcher differs by HyDE vintage:
- current HyDE: systemd user unit `hyde-<XDG_SESSION_DESKTOP>-bar.service` (auto-restarting) —
`systemctl --user stop <unit>; systemctl --user mask <unit>`.
- older (pre-unit) HyDE, e.g. wm's: `exec-once = $start.BAR` in HyDE's generated `hyprland.conf`
— neutralized by `$start.BAR=` in `gui/.config/hypr/hyde.conf` (empty = unset; hyde.conf is
sourced before that exec-once). Current HyDE's `variables.conf` re-sets `$start.BAR`, so that
line stops working after an update — see HYDE-UPDATE.md step 4.
Note: the Arch `waybar` build has **no native `cava`** module — the rig uses the script module
`custom/cava` running `cava-waybar.sh` (self-contained, no HyDE dependency).