I'm wondering if there is a new tool out there that I'm missing out on.

all 31 comments

sorted by: hot top controversial new old
[–] 3 points 3 years ago (1 child)
  • [–] 3 points 3 years ago

    Git and symbolic links still.

    Ive heard good things about GNU Stow.

  • source
  • [–] 2 points 3 years ago*

    I use git (without remote repo, but could be easily added). Actually this simple bare git repo technique is something I enjoy doing in lots of places where config files lie.

    Basically, it's only: alias config="/usr/bin/git --git-dir=\${HOME}/.myconf/ --work-tree=\${HOME}"

    Of course, a first time setup is required:

    git init --bare $HOME/.myconf
    config config status.showUntrackedFiles no
    

    I got this setup from a comment on HackerNews long ago. OP comment was rather insightful: "No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation."

    But I never used any branches, prefer to keep it extremely KISS. I even avoid commiting, just staging area that I keep updating with each OS upgrade. Only this bit of extension I use... since I don't push to any remotes (prefer keeping dotfiles private), I needed a way to copy all of the tracked files (e.g. to have my settings on a work laptop, of course I then go ahead and clean any boilerplate before moving such an 'exported' folder)...

    config_export() {
        echo "Copying only staged files, it is recommended to run beforehand: $ config add -u ~"
        mkdir -p ~/.config_export/
        CONFIG_FILES=$(config status | /usr/bin/grep 'new file:' | cut -d':' -f2 | sed -E 's/^ +//')
        printf "%s\n" "${CONFIG_FILES[@]}" | xargs -I {} cp --parent '{}' ~/.config_export/
        ls -halt ~/.config_export/
    }
    
  • source
  • [–] 2 points 3 years ago

    I'm surprised it's not already mentioned in these comments: https://yadm.io/

  • source
  • [–] 1 point 3 years ago

    Tried all the fancy ideas, never stuck with it. I just use git to track changes now and move on with my life. There are like four functions I carry around with me, then whatever path additions and init scripts I pile up. It’s so light it doesn’t really matter when I move to a new machine

  • source
  • [–] 1 point 3 years ago*

    i take a Phoenix approach with my dotfiles.

    Once a decade when my computer crashes and burns, from the ashes emerges a blank slate of dotfiles that is purged of all unnecessary hacks that have accumulated. With a tear and a hopeful outlook, I rush to set the settings I am actually dependent on.

    I really need to take more interest in backing up my dotfiles 😭

  • source
  • [–] 1 point 3 years ago

    I still put them in gists, with no real tooling. I pull them in selectively when I get a new machine.

  • source
  • [–] 1 point 3 years ago

    I used bare git repo before, then switch to GNU Stow + Nix home-manager.

  • source
  • [–] 1 point 3 years ago

    They're in git

  • source
  • [–] 1 point 3 years ago (1 child)

    @no_sle3p I have them in a Git repo and I use GNU Stow to symlink things. I also wrote a blog post about this with more details: https://evanhahn.com/a-decade-of-dotfiles/

  • source
  • hideshow 2 child comments
  • [–] 1 point 3 years ago* (last edited 3 years ago) (2 children)

    Are you me? I do the exact same thing.. only I also made a Makefile to do all the stow commands for me.

    https://github.com/mrkite/dotfiles/blob/master/Makefile

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 3 years ago

    I use yadm. It's a wrapper around git with a few extra commands for dotfile management.

  • source
  • [+] 1 point 3 years ago* (last edited 2 years ago) (1 child)
  • [+] 1 point 3 years ago* (last edited 8 months ago) (1 child)
  • [–] 1 point 3 years ago

    Yep it's like maintaining a codebase that's getting increasingly better. It's a rabbit-hole and a timesink (kind of because you're trying to get the best out of it, and thus configure likely more) but I think it's worth it. It gets better overtime as well

  • source
  • parent
  • [–] 1 point 3 years ago (1 child)

    I prefer to keep tooling for that at a minimum. Therefore I use git only. My approach is taken from here: https://www.atlassian.com/git/tutorials/dotfiles The only difference: My git alias is dotfiles not config. I find that to be less confusing. Additionally, I source system-specific configs, where appropriate. These are not stored in dotfiles. There is a small todo section in my readme.

  • source
  • hideshow 2 child comments
  • [–] 1 point 3 years ago

    I store them in Dropbox and symlink them to their correct location.

    I do that instead of the standard Git method because it means I don't have to worry about remembering to sync each computer. Everything syncs immediately.

  • source
  • [–] 1 point 3 years ago

    https://github.com/technicalpickles/homesick
    It's a bit old (hasn't been updated in 4 years), but works great.

  • source
  • [–] 1 point 3 years ago (2 children)

    https://www.chezmoi.io/ if you've got some complexity with your setup. otherwise, could be overkill.

  • source
  • hideshow 4 child comments
  • [–] 1 point 3 years ago

    I use Chezmoi but I have to point out some of its downfalls vs. other dotfile managers, particularly if someone is looking to migrate to it.

    • Go's templating lib is incredibly unergonomic.
    • Identifying file perms and visibility in by special naming convention is pretty gross. Also makes it more difficult to migrate to another solution.
    • If you're deleting files, you need to remember to do it through chezmoi remove .... You can't just rm them from your dotfiles directory, because chezmoi does not sync state; it simply applies what's currently in your repo.
    • Handling multiple systems through .chezmoiignore ends up being overly verbose and unintuitive vs. the approach used by other dotfile managers

    Despite these gripes I still use it because deployment via a single binary is convenient, and there's enough control through the generated config file + system info to handle multiple kinds of deployments sort-of-sensibly (see point 4 above).

  • source
  • parent
  • [+] 1 point 3 years ago
    [–] 0 points 3 years ago* (1 child)

    I've done symlinks into a separate directory before, but by far my favorite method is to just let ~ be a git repo. It's maximally simple, no other tooling needed besides git.

    There are a few key steps to making this work well:

    • echo '*' > ~/.gitignore: This way git status isn't full of untracked files. I can still git add -f what I actually want to track.
    • git branch -m dots: For clarity in my shell prompt.
    • [ -d "$HOME/.local/$(hostname)/bin" ] && PATH=$PATH:$HOME/.local/$(hostname)/bin and similar if there's config I want to apply only to certain hosts.
  • source
  • hideshow 2 child comments
  • [–] 1 point 3 years ago (1 child)

    Pretty happy with nixos these days, after the initial (crazy) learning curve. But I really like the creative simplicity of this idea

  • source
  • parent
  • hideshow 2 child comments