A Way to Manage Dotfiles
github.com
A Way to Manage Dotfiles
1–10 of 44 posts
Re: A Way to Manage Dotfiles
#2Re: A Way to Manage Dotfiles
#3I like the bare repository approach here. I've been using symbolic links to version control my dotfiles with git.
Re: A Way to Manage Dotfiles
#4I like the bare repository approach here. I've been using symbolic links to version control my dotfiles with git.
Re: A Way to Manage Dotfiles
#5[0] https://github.com/podiki/dot.me
[1] https://www.gnu.org/software/stow/
[2] https://github.com/podiki/dot.me/blob/master/x11/README.org
Re: A Way to Manage Dotfiles
#6The first is that I have a habit of running `git add .` when I'm working on source code, and as a result I have accidentally added my entire home directory to the bare repo more than once... Easy enough to undo but a bit inconvenient. `dotfiles add -u` is the safe option, or just be explicit about which files you are staging.
The second issue is the 'branch per machine' approach, which I do use. I have two machines I use regularly, and a third occasionally. There are some bits of config (e.g. for vim) that are shared across all the machines, while other bits are not. If I use one machine for a while, then I end up with lots commits that I need to cherry pick when I next use another machine. Depending on how long it has been, this can be a bit of a faff.
Finally, because there is no clear mainline branch, you have to pick commits to/from any of the branches. If you are undisciplined like me, then this will leave you with a 'three way ahead and behind' scenario at some point.
Anyway, I like the approach overall. If anyone has a suggestion to ease those pain points I'm all ears.
Re: A Way to Manage Dotfiles
#7Re: A Way to Manage Dotfiles
#8Re: A Way to Manage Dotfiles
#9I've been using this bare repository approach for a while. I forget where I first saw it, I'm pretty sure it was on HN but it was not this project. I do like it, but I have a few minor issues. The first is that I have a habit of running `git add .` when I'm working on source code, and as a result I have accidentally added my entire home directory to the bare repo more than once... Easy enough to undo but a bit inconv…
I combined the bare repo approach with a per-machine custom branch approach described in https://www.anishathalye.com/2014/08/03/managing-your-dotfil...
The idea is that you have the shared configuration in one repo, and at the end of each config file, you include a local version. The local versions live in a separate repository and use a separate branch for each machine.
For example, at the end of .bashrc, you'd have
if [[ -r $HOME/.bashrc_local ]]; then
. "$HOME/.bashrc_local"
fi
and so on, for each config file. My general dotfiles repo is public here, if you want to take a look how I did it for the tools I use: https://github.com/bewuethr/dotfilesThis still isn't ideal. For example, I use Git submodules for Vim plugins in the shared repo – but maybe I don't need all of that on my Raspberry pi. I feel like at some point, a config file based solution could be better; or using a tool such as https://yadm.io/, which is using bare repos under the hood.
Re: A Way to Manage Dotfiles
#10 for FN in ~/.paths/sneak-sync/bashrc.d/*.sh ; do
source $FN
done
Then updates (by adding or removing files to these directories) propagate to all my workstations. I have machine-specific ones, too, that also sync but aren't included due to differing hostnames.