thomas.koppandClaude Opus 5
4b38b80875
Task 7 as planned would have checked out over shron and reviewed what was lost afterwards. That is the wrong order for a machine whose .zshrc holds working operational tooling: ipt-block, a CrowdSec whitelist helper, reboot_required, the German locale and dircolors would all have been gone between the checkout and the review. Also found: shron runs ZSH_THEME="ys" and has no powerlevel10k. The theme selection would have fallen through to oh-my-zsh's default, which is a regression nobody asked for, so 05-pre-omz.zsh keeps ys where p10k is absent. The red role colour is still set, but it is honest to say it does nothing there until p10k is installed - the safeguard the role split was built around does not currently apply to the one machine it was meant for. 05-prompt.zsh becomes 05-pre-omz.zsh: the theme was never the only thing that has to precede oh-my-zsh. DISABLE_AUTO_UPDATE belongs there too - a server should not go fetching updates on its own while somebody is logged in fixing something - and the stub no longer sets the update mode itself. update-blacklist is carried over with a note rather than silently: openbl.org answers 301 and the curl call has no -L, so it has been reporting "Blacklist download failed" for some time. CrowdSec covers that ground now, but the iptables chain it created may still exist and is worth removing deliberately. PYTHONPATH pointed at python3.4 on shron and at 3.9 on beastix. Neither directory exists; neither is carried over. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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