You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. :)
0 commit comments