thomas.koppandClaude Opus 5 003ba4b390 feat(mobile): the Mac role, and role-dependent plugins
Looking at the actual machine turned up something the shared plugin list could
not express. The Mac loads macos, brew and dotbare; beastix and shron load
archlinux. One list filtered by availability - which is what the stub did -
would have dropped four plugins on the Mac without a word. Assembly moves into
05-pre-omz.zsh, which knows the role, and the availability filter stays on top
of it so a plugin that is not installed still cannot produce a warning at every
login.

.zprofile is added, and that is the whole point of the mobile role. The Mac
sets its PATH in .zshrc, so /opt/homebrew/bin exists for interactive shells and
for nothing else: "ssh mac brew --version" comes back empty, which during the
design phase was read as Homebrew not being installed. It is installed, with
178 formulae. Homebrew's shellenv belongs in .zprofile and now lives there; the
loop is inert on Linux, where neither prefix exists.

Carried over from the Mac: the Homebrew auto-update settings and bench(), which
runs bench inside the ERPNext compose stack.

PYTHONPATH pointed at /usr/lib/python3.9/site-packages there too - a Linux path
on macOS, so doubly wrong. All three machines had a variant of that line and
none of them is kept.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 14:11:58 +02:00
2021-04-04 05:08:32 +02:00

DISCLAIMER:

this is not my work I've the idea from https://developer.atlassian.com/blog/2016/02/best-way-to-store-dotfiles-git-bare-repo/

In his words the technique below requires:

No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.

but for reason: ;)

  • git and
  • curl

How it work

The technique consists in storing a Git repository in a "side" folder (like $HOME/.cfg or $HOME/.myconfig) using a specially crafted alias so that commands are run against that repository and not the usual .git local folder, which would interfere with any other Git repositories around. Starting from scratch

If you haven't been tracking your configurations in a Git repository before, you can start using this technique easily with these lines:

git init --bare $HOME/.cfg
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
config config --local status.showUntrackedFiles no
echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc

The first line creates a folder ~/.cfg which is a Git bare repository that will track our files. Then we create an alias config which we will use instead of the regular git when we want to interact with our configuration repository. We set a flag - local to the repository - to hide files we are not explicitly tracking yet. This is so that when you type config status and other commands later, files you are not interested in tracking will not show up as untracked. Also you can add the alias definition by hand to your .bashrc or .zshrc or use the the fourth line provided for convenience.

I packaged the above lines into a snippet up. So that you can set things up with:

curl -Lks https://ls.shron.de/dotconf | /bin/bash

After you've executed the setup, any file within the $HOME folder can be versioned with normal commands, replacing git with your newly created config alias, like:

config remote add dotconfs url.to.remote.repo
config checkout
config status
config add .vimrc
config commit -m "Add vimrc"
config add .bashrc
config commit -m "Add bashrc"
config push

Install your dotfiles onto a new system (or migrate to this setup)

config pull
S
Description
No description provided
Readme
243 KiB
Languages
Vim script 75%
Shell 25%