1. 7
  1.  

  2. 4

    They write a list of things they dont want - custom commands using some programming language that might not be installed, but ended up creating a manager in go?

    … what about tracking the XDG_CONFIG_HOME directory in plain git?

    1. 1

      I mean, I probably would’ve just used a big shell script, but everyone has their own kinks.

      1. 1

        Maybe because most of the programs i use honour XDG_CONFIG_HOME, i don’t need a script or program to setup the symlinks (2 at the moment - for the shell). This makes this stuff much easier.

    2. 3

      Some time ago I realized that I am most happy when deleting parts of my dot files, not managing them. In my opinion people who end up writing their own dotfile managers will never see the end of it. Likely you will never be in a place where you are finally satisfied with every custom change and have it “perfect”. Adding, changing, adapting, sharing, updating, tracking, managing and then remembering stuff about the config files becomes a chore.

      Change a few selected parts, set up $XDG_CONFIG_HOME like others here have said, back it up (maybe using git). That is where this story ends for me.

      1. 1

        For a while now I’m using this solution, which I found when I was searching for a good solution to track my dotfiles with git:

        alias config='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'
        config clone --bare ${REPO_BASE}/.dotfiles.git $HOME/.dotfiles
        config checkout --force
        config config --local status.showUntrackedFiles no
        

        This is really easy to use. You add the alias line to your cli-configuration (bash, zsh, …) and then use it almost like git. Like config add ~/.vimrc ; config commit ; config push origin master.

        It’s almost zero dependency, it only needs git.

        Beware the --force at the checkout.

        1. 1

          FWIW Atlassian has a helpful article detailing this approach:
          https://www.atlassian.com/git/tutorials/dotfiles

          Personally I prefer not turning my entire $HOME dir into a repository, keeping my dotfiles repository separate, and running a small program I wrote to symlink things between them. Your approach (that I first learned about in that Atlassian article) is attractive, however, because it’s the first one I’ve seen that uses git to manage your home directory without making your entire HOME look like a gigantic git repo since it uses a non-standard .git dir, and it doesn’t require you to constantly add things to your .gitignore because it explicitly ignores all untracked files.

          Beware the –force at the checkout.

          Yeah one of the reasons I prefer my homegrown thing is because it’ll automatically back up any files it encounters that you have in your dotfiles repo, so it’s easy to bootstrap on a machine without worrying about trashing anything that’s there.

          1. 1

            Oh yeah, thanks for the reference. I think that’s the page where I discovered this approach.

        2. 1

          Consider https://chezmoi.io - it’s a dotfile manager with many of the features that you want and is very quick and simple to get started with.

          1. 1

            I personally found that the problem with dotfiles was that they’re very hard to share in a team. One of my pain points was getting new team members up and running quickly (ie. have all their tools properly setup) and also be able to go on their workstation and switch to my own configuration so that I can type property (I use vim bindings pretty much everywhere). I made dotenv to solve these problem, it’s still a bit rough but has done the job fairly well so far – maybe it can be helpful to other people as well!