Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Switch from installing dotfiles via lndir to using Git work-tree
I've read about installing dotfiles entirely via Git using the --git-dir and --work-tree flags and this is an experiment to try that approach to see if I like it. Previously, I would clone my dotfiles repository somewhere and then symlink all the files from that directory into my home directory. E.g., `lndir $HOME/src/dotfiles $HOME`. The `lndir` package is available in most distros, sometimes under one of the X11 packages, or installed along with XQuartz on OS X. I wrote a (much) slower and simpler version as a shell script for environments where it wasn't available (Termux, mingw, headless boxes). I like the symlinks approach quite a bit and I have used it for at least the last 13 years: *Pros*: - It is a very minimalist solution; both simple and straightforward without reliance on crazy scripts, directory structures, or installation steps. - I can install it on a fresh system with two commands that are easy to remember and type. - It provides a separation for in-progress files or changes that can get symlinked only when ready. - Working on dotfiles is the same workflow for any Git repository. - It is not a Git-specific solution and will work with anything that maintains a directory of files. (My dotfiles pre-date Git by many years. See 882c3ac for reminiscing.) - It's a nice way to "overlay" files and directories that I care to version-control with files I don't care to version-control and want to ignore. *Cons*: - There are two steps needed to create then install a file (sometimes a pro, sometimes a con). - Old, broken symlinks need to be removed from time to time (easily done with `find . -xtype l`). - I can only think of twice in all this time that having a symlink on disk rather than a real file caused a problem, but it has happened. - While it's possible to compare/contrast the installed files I am version-controlling with sibling files that I am not, doing so isn't straightforward -- in particular, my `~/tmp` directory tends to accumulate cruft (and obviously the normal cruft under `~` as well). Using a relocated Git work tree is decidedly less simple than symlinks. That said, Git has become a staple of my daily workflow and I use it to _think_ every bit as much as I use it manage files and versions. It is extremely fast for inspecting and updating the file system. It means one less dependency needed for installation. There's a slight appeal to managing files directly instead of links to files, and Git's normal workflows will make it straightforward to identify different kinds of cruft that will show up as untracked or ignored files. So let's try it. The changes below are needed as follows: - My name choice for the global excludesfile conflicts with having a dotfiles-specific `.gitignore`, so I need to rename the global. - The `.gitconfig-customize` file was intended to be per-project and I mistakenly anchored that to `$HOME`. This fixes that and allows for version-controlling the config that ignores untracked files that is a staple of the Git worktree approach -- no post-installation `git config --local` changes needed, just clone, checkout, and done. - I'm going to experiment with ignoring specific, common files in my home directory. Obviously ignoring all the noise files that accumulate there is impossible, however ignoring some of them will remove some noise when manually inspecting ignored files and will help with the occasional cruft cleanup efforts. - I think the usual approach of using a shell alias to access Git commands is clunky _at best_. I'd like to avoid it even though that means adding a little Zsh/tmux machinery. - Update various hard-code paths to my dotfiles. If this experiment doesn't work out then I can revert this commit and it will have been fun to try something new. :)
- Loading branch information
