-- Leo's gemini proxy
-- Connecting to ew.srht.site:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
~ew0k ponders the merits of version control at $HOME at least regarding fiddly dot files.
Yes, of course, noone wants to be forced to recrecreate fiddly dot files in a hurry, and at the least convenient time.
So?
I can identify at least four iterations of how I did it over time.
Once I realized the importance of flawless dot files I just created plain copies of said files in a folder, ~/00.dotfiles, say. I might even have had a script to collect them, possibly adding a date suffix or date folders or something such. I cannot remember if I used RCS[a,b], the version control system available at the time.
Those dot files get company at some point, e.g. scripts and small programs living in $HOME/bin. At this point copies become questionable. But there is a good tool to deal with sets of symlinks: stow[c]. And I did use this for a set of extra programs local to my account.
I was late to use git, but one of my use cases was combining vcsh[d] and myrepos[e] to version control dot files and the like plus adding a remote repository to it. This remote repository lived on a USB flash drive. Ok this is not remote and always online, but at least it provided a copy of everything in a location away from the computer.
I made two sets of files managed by vcsh:
ew-env holding said dot files. The current list includes ~/.bash_logout ~/.bashrc ~/.config/i3/config ~/.config/i3status/config ~/.gitconfig ~/.inputrc ~/.login ~/.profile ~/.Xdefaults ~/.xinitrc-i3 ~/.xmodmap
ew-run holding holding a set of scripts, that I like to have around.
No ssh keys or config though.
As ~ew0k has pointed out, having '*' as the only entry in ~/.gitignore forces you to explicitly add every controlled file every time. I had read this suggestion earlier in a blog entry by Drew Devault[f]. And I have tried it on my new systems. It works well. I create a branch named $HOSTNAME on every machine, and I add a remote repository, which is a cgit instance provided by my little home server[g].
So, the remote is on a separate machine. The separate machine is being backed up to still another machine --- well I shoud sync this backup to an external disk, maybe.
Still no ssh keys.
Now, how does ~ew go about ssh keys and the like? Well, I have gone a different route for that for a long time. It started with purchasing my very first USB flash drive many years ago. I learned to put several partitions on the flash drive. The first of them is a FAT partition to please Windows and reduce the risk of formatting the drive prematurely. I learned to use crypt-setup and luks to create one encrypted partition. I added a fancy shell script to automate mounting the partitions of the stick after login, and prior to starting Xorg/i3. I added more fancy scripts to link and relink directories. This is where the ssh keys come in.
~/.ssh is a symlink either to ~/L/ssh or ~/U/Z/ssh. ~/L/ssh is a local directory just holding my local key for this system, a config and a knownhosts file. With this symlink I can use the machine. However, ~/U/Z/ssh is a directory on said encrypted partition on the flash drive. It holds the entirety of my keys and configs. Without the mounted USB flash drive (well a fancy NVMe thing nowadays) I am quite limited in what I can do.
The same linking goes on for ~/.gnupg and ~/eOrg, where my emacs/org-mode files live. Without this flash drive, I am basically dead. So there exists a backup flash drive, which gets synced once per week. These files do NOT end up in my regular backup.
Where's th code? StuffOnStick[h] is hosted on sourcehut. I chose GPLv3 as a license, feel free to use it. There is even some documentation.
Your dotfiles, keys, config, favourite scripts and files are precious.
You don't want to hunt for them in inconvenient times
You don't want them to become public either
You still want backup copies
You want to use encryption to render the lost flash drive uninteresting to the one who finds it
Use whatever works for you, whatever you understand sufficiently to not be at mercy of some 1password or similar online service, which might cease to exist at the least convenient time.
Cheers,
~ew
-- Response ended
-- Page fetched on Fri May 3 03:48:04 2024