1. 7

  2. 3

    I am not sure how I feel about this, just because I tend to have a server config, a local config, and a pairing config. I had some homegrown scripts to manage it but then after many years of iterating, I landed on gnu stow where I can easily swap things around. It isn’t completely perfect but so far, the best I have found.

    1. 1

      It isn’t completely perfect but so far, the best I have found.

      I use home-manager to manage software and configuration jointly in declarative manner. On a new machine, I check out my home-manager configuration, run home-manager switch and I have my configuration + all the software.

      1. 1

        I still need to try this out after I looked at John Wiegleys setup. Right now I do something similar in that I use org-mode and babel to export/compile my dotfiles and then rsync them to wherever they need to go.

        Bonus is this means I can “compile” my dotfiles with whatever setup I want and sync them to wherever without needing the source inputs. I’m just worried about portability for nix stuff on os’s like openbsd etc…

    2. 4

      This is not a very good idea, IMO. Many utilities/tools tend to create folders and files in the home directory, like Ghidra for example, creates a ~/ghidra_scripts. It’s bound to get messy fast. It’s probably a better idea to maintain a separate “dotfiles” folder where you symlink config files/folders that you want to persist across installs, and version that using git instead.

      1. 3

        What do you mean?

        The first line in the ~/.gitignore file causes it to ignore everything. Anything you want to track you need to add explicitly and new files won’t even show up in git status.

        1. 2

          Oh right, yes. My bad. I’d failed to notice the first like in your .gitignore.

          1. 1

            Not mine, but yeah I wondered :-). I’m using the more traditional dotfiles approach as well.

            I had actually tried to put my home dir under git ages ago, running exactly into the issues you’ve mentioned. Ignoring everything by default and only adding files explicitly does sound like an interesting alternative to consider at least.

        2. 1

          This argument makes sense to me when it comes to synchronizing two or more different computers.

          What kind of version control systems is preferable when it comes to the synchronization/backup of the ~/Documents folder alone? I guess syncing Windows/Linux mashines should not be a problem here, no?

          I using rsync for backups these days, and never thought about looking into version control systems. Any experiences here?

          1. 2

            It depends. If your files for backup are generally text based, i.e. config files, then using a VCS is a good idea. Something like git offers great ease in managing them. But if your files are binaries, like pictures for example, then rsync is alright, I guess.

        3. 2

          I found a utility called rcm that I use to manage my dotfiles. It allows me to only install certain dotfiles on a given host. It also allows me to have host-specific dotfiles.

          For example, I have a .gitconfig.local that is included in my main .gitconfig. For work, I include my work email and for home I include my personal email.

          1. 2

            I’m using this style of dotfiles as well. It works okay, but I think I should migrate to a subdirectory for the reasons others have mentioned in the comments and here. I additionally use submodules for Vim plug-ins.

            1. 2

              What I don’t like about this type of dotfile management (I used to have a dotfiles git repo) is that the configuration for specific things are splatted across configuration files. E.g. if you configure the Kitty terminal emulator, you have Kitty’s own configuration file, you add a kitty command to your .zshrc to enable completions, perhaps you add KITTY_DISABLE_WAYLAND to your PAM session variable configuration to disable the Wayland backend. Now if you want to remove Kitty, you have to update your configuration in three places.

              IMO configuration should be declarative. Enabling Kitty means that (1) the program should be visible in the user environment; (2) the program’s configuration should be in the proper path; (3) the completions should be added to the zsh; (4) the PAM session variable is added. When you disable Kitty, 1 to 4 should not be true anymore.

              Even though it is not perfect, home-manager has been the closest thing I have found so far for declarative configurations for home environments. E.g., kitty

              1. 2

                I do this and even wrote a tool to make it easier:


                The trick here is the .gitignore which will ignore everything by default, so you have to git add -f any file you wish to keep around.

                # This gitignore is meant for the home directory repo itself, and
                # ignores any files that aren't explicitly added to Git.
                1. 1

                  I do this, but because I am careless, I added a git-clean script that lives in my $PATH before the system git that looks for a .git-noclean file at the root of a checkout, and, if it exists, exits with an error. Because I can all too easily see myself typing git clean -f -d -x in what I think is the right terminal window …

                  ETA: Actually, I do this with a fish function. I can’t remember why I switched away from a shell script, but eh:

                  function git
                          if test $argv[1] = "clean"
                                  set git_base (git rev-parse --show-toplevel)
                                  set ignore_file $git_base/.git-noclean
                                  if test -f $ignore_file
                                          echo "JFB: cannot clean $git_base (ignore file exists)"
                                          return 1
                          hub $argv