Dotfiles: Unofficial Guide to Dotfiles on GitHub | Hacker News Reader

Dotfiles: Unofficial Guide to Dotfiles on GitHub

dotfiles.github.io

229 pointsstefankuehnel71 comments

This site seems much more like an some of the awesome-<insert tech here> repositories on github than a guide. Although it does give some extra information on the packages.

To not make it took negative. I personally use Chezmoi, which I've been super happy with. The ability to maintain files in a central repository and then pull them into the file system on an update is quite nice.

You can handle merge conflicts and whatnot between your local copy and the upstream dot files. You can opt your files into using go templates in your files which is useful when I need to maintain differences in configs between mac and linux, or in general for just storing secrets out of your dotfiles.

There are some small annoyances but overall it is the only dotfile manager, I've managed to stick with.

Seconding Chezmoi, it's what I use, and it works well.

Third here, it's the easiest tool to setup dotfiles that work on machines ranging from RHEL7 to latest MacOS. Haven't dealt with Windows dotfiles though.

Fourthing Chezmoi. I tried so many dotfiles tools and it's the only one that does just enough, gets out of my way, and "just works".

Being able to run `chezmoi diff` and `chezmoi apply` are game changers.

Another happy chezmoi user here... I progressed from symlinks -> Homeshick -> yadm -> chezmoi

One of chezmoi killer features is how it handles secrets. Either the secret can be encrypted using age/gpg or (super cool) it integrates with you password manager (I used Bitwarden).

This is super useful for me, as I pair chezmoi with dotenv, so when I switch directories, my environment variables are auto populated, including secrets that are pulled directly from my password manager.

I guess I don’t quite get it. It’s not a ton of work for me to manage things with git, symlinks, and a makefile. Clearly chezmoi adds some polish and maybe additional features, but I don’t see how that outweighs learning a custom tool for this one thing.

I just use stow and git with a Makefile as well, and I could certainly do without stow these days (I can just write a Makefile target for it, but haven’t bothered).

I just back up my files to USB drive, and then transfer them to new machines manually.

The thing is that there isn't a lot to learn unless you have complex use cases (I have one, so I need to use chezmoi's advanced features). It just uses git under the hood and does a diff between your repository and the actual locations of your dotfiles, so if you wanted to (and I often do) you can just `cd` straight into chezmoi's repo and use `git`.

My complex use case is that I use all three of the main OS' and so there are some dotfiles for desktop apps that live in Windows' home directory and some that live in WSL, so having something manage that for me is pretty nice.

All you need is a symlink script that symlinks files in ~ to ~/path/to/your/dotfiles

https://github.com/pprotas/dotfiles/blob/main/symlink.sh

That's it.

This will not handle cases other targets than $HOME. The automatic deletion seems also very risky. In my own script, I move all pre-existing targets to a separate directory, so I can check later.

You can set the source and target directories to whatever you'd like, this is just what I need for my own use. The automatic deletion is for directories, to prevent recursive symlinks. Of course, you can program your own however you wish, maybe add a confirmation step before removing and/or create a backup beforehand.

Using the GNU stow utility makes this super easy. It even has a --dotfiles flag so you can author your dotfiles as dot-zshrc and when the utility symlinks it, it will be .zshrc. Makes it nice so your source files are not hidden but the actual dotfiles are (as expected).

Although GNU stow is very interesting, I like this simple script because it has no external dependencies. Stow is not available on macos by default, for example.

It is available though in every package manager for macOS except the App Store, and any user of a script like this on macOS is probably also using Homebrew, macports, Nix, or srcpkg.

I got mine from brew. Like 90% of my userland, really.

I use stow, which has some nice advantages vs managing symlinks yourself

https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-t...

Sure, maybe. Though eventually one may find lots of edge cases. What about files in the root that get deleted? What about programs that put wanted state within config dirs? What about programs that ignore symlinked files? What about when you’re hacking on your dotfiles and break everything because the active config is the config being edited? What about when you need to vary based on system? What about…

I mean, yea, if it works for you, great! But all of the above are problems I did have. I grew a custom install script for years. Now I use Home Manager and the impermanence module.

Similar experience here, like: What about when your editor is set to auto save when unfocusing a tab or window and saves while you were mid-edit on your dotfiles and now every new shell is crashing? etc etc

My approach to coding is to tackle these types of problems once they occur, instead of thinking "What about...", "What if...". I don't have these problems you're describing, so the script works great.

I made it Python, added a simple json-config and mustache-templating. Very portable (where symlinks are), very flexible (also used it for termux for a bit) and very simple.

Yeah, same: https://github.com/vbezhenar/dotfiles/blob/main/ln-all

No need for those complex software, just shell script is enough for me.

I'm sorry, but running `rm -rf ...` in a script against $HOME is a bit too reckless for me.

Maybe you haven't lost data from this yet, but this is where Chezmoi has nice guardrails and protects against, e.g., modifications or additions accidentally being made to $HOME instead of the dotfiles dir, which look like they would be silently blown out by your current process.

Just my 2¢ from someone who used to do it this way and lost data because of it.

What do you think is the risk here? I don’t see a code path to remove my home dir in the script

EDIT: Unless I have a dir called "*" in my dotfiles, but at that point I deserve to have my home dir removed :P ZSH also asks for confirmation first

I think I'm the only person insane enough to use a makefile for this.

https://github.com/matheusmoreira/.files/blob/master/GNUmake...

https://www.matheusmoreira.com/articles/managing-dotfiles-wi...

It even supports the XDG stuff as well as variables like GNUPGHOME.

Nope. There are at least two of us out there.

I've been bikeshedding with dotfiles for 20 years and ended up with Chezmoi[0] in the end.

It came down to the fact that it's easy to install and easy to bootstrap as long as your dotfiles are in a public Github repo. It also integrates with a bunch of password managers to grab any secrets you might need in addition.

I use the "run_onchange_install-packages.sh.tmpl" to install basic packages to computers I bootstrap chezmoi on, it adapts based on the operating system using chezmoi's templating system[1]

It takes a few tries to remember the flow of "chezmoi add"ing a file after editing it so that you can push it to Github. After that it's just a matter of chezmoi update on your other computers to bring them up to date.

For .gitconfig I use a .gitconfig.local file on my work computer to override my personal credentials and not have to mess with templating the file.

[0] https://www.chezmoi.io [1] https://www.chezmoi.io/user-guide/advanced/install-packages-...

just setup a bare repo and call it a day.

https://www.atlassian.com/git/tutorials/dotfiles

original thread on HN: https://news.ycombinator.com/item?id=11070797

This is how I manage my dotfiles, and it has worked pretty well for me.

How do you handle differences between machines (e.g. between Linux and macOS)? How do you handle secrets?

I can't speak for the OP, but I've used a bare git repo for a number of years to manage my dotfiles, and in the few cases where I need to handle differences between machines, I've always been able to find a simple and straightforward, albeit ad-hoc, solution: for my shell, I `source local-config.${hostname}` when it exists; for my emacs config, I have a couple `cond` blocks in my config.el file; my preferred terminal emulator (kitty) can load multiple configuration files in sequence via passed arguments, so I can write a simple wrapper script and use a per-machine override .conf if necessary; etc etc. I don't currently put secrets in any text configuration files (nor can I envision myself doing so in the near future; I generally use a password manager, ssh/scp, or magic-wormhole to move secrets between workstations and servers where I have a user account), so I don't have a good answer for that one.

I imagine these solutions would scale poorly if I had a large number (dozens? hundreds?) of machines which all needed unique configurations, or if I used more tools which needed per-machine configuration, or if I needed to stick secrets in configuration files for some reason. Luckily for me, that's not the case, and my system has served me quite well as a result.

Pseudocode:

    if “$TERM_PROGRAM” != “”; then
        # think diff’rnt
    else
        # tron leotards
    end

All you need is gitignore: https://github.com/chapmanjacobd/computer/blob/main/.gitigno...

For me, I have found nix home manager to be the most effective solution for managing my dotfiles.

The migration process was easy, and I was able to use it to replace my sim link script with it's file directives.

It also integrates well with my Nixos Systems.

Nix + Home Manager is by far the easiest-to-manage system for dotfile management to date for me.

The added bonus is:

1. No need for complicated directory structures that a symlink-like script needs to manage.

2. Dotfile management coupled with package management. Dotfiles only make sense as configuration to packages you have - why would you not tie these together?

3. Minor-to-no tweaks required to have a fully reproduced setup on any machine.

Seriously, I transitioned my dotfiles from my NixOS machine at home to my work-issued M2 within... an hour?

I will never not evangelize Nix.

I have also ended up with Home-Manager. It's an extremely powerful tool that I am unlikely to replace in the next ten or so years, but you also need to learn a whole programming language (Nix) plus a DSL (the NixOS module system) to get the most out of it.

On the upside: you do get a whole purpose-build language for configuring your system, piecing together your configurations dynamically, installing your packages and so much more.

Ability to install packages is another huge thing. Home-Manager does not just configure my tools, it also installs them (including my DE), so I can get started with my custom config on a new system in a matter of minutes.

I started managing my dotfiles in git and followed the pattern I found in Anders Knudsen's repository below. The most painful thing has been coming up with config that works across Linux and MacOS, but that's been chosen pain that can easily be avoided.

https://github.com/andersix/dotfiles

I have been keeping them in separate branches because I have had macOS with intel and arm because there were differences in the config.

yup, a bare repo. its the easiest way I think.

This method, using a bare git repo, is really an elegant, efficient, and easy way to manage one's dotfiles.

In the end, how you do it is personal pref. I liken it to editor wars, vim vs emacs, etc. What works for me, may not work for you.

PS: these are my dotfiles (link is my repo), and I've used this method for some 5 plus yrs now and it works well for me. I really like how easy it is to spool up a new linux instance and have my config ready to go in mere seconds.

I've not used branches yet, for different OS'en, so my zshrc and bashrc have conditional checks for OS. I will be looking at using branches in the future since it does sound like it would make shell rc files cleaner.

Symlinks and Git. A remote like GitHub is then a minor bonus.

I didn’t store my dotfiles on GitHub because they didn’t used to have free private repositories. (Why would I share my dotfiles?)

Gnu stow has finally been updated to fix a long standing issue so I can once again wholeheartedly recommend it again! It’s lightweight and uses symlinks. Last I checked, chezmoi has a symlink mode but it’s a bit worse.

Curious what the issue you were running into was? I’ve been using stow for my dotfiles for at least 8 years now and have been loving it the whole time.

Sorry - should have been specific in top-level comment. I was referring to this one: https://github.com/aspiers/stow/issues/33

Basically, the --dotfiles option was not working with directories so you had to have things that look like this: lazygit/.config/lazygit and now it looks like: lazygit/dot-config/lazygit.

Really a small issue that bugged me forever - shouldn't have made it seem like it was core a problem with stow!

What's the issue? I've been using stow for a decade now and can't recall ever running into problems

Sorry - should have been specific in top-level comment (cant edit now). I was referring to this one: https://github.com/aspiers/stow/issues/33

Basically, the --dotfiles option was not working with directories so you had to have things that look like this: lazygit/.config/lazygit and now it looks like: lazygit/dot-config/lazygit.

Really a small issue that bugged me forever - shouldn't have made it seem like it was core a problem with stow!

I guess you're referring to this ? https://github.com/aspiers/stow/issues/65

Sorry - should have been specific in top-level comment. This one: https://github.com/aspiers/stow/issues/33

I'm currently using a git based approach for my dotfiles, similar to the one notes here[1]. I've got one significant change, though: All my dotfile management works over my cfg[2] script that helps me maintain a main branch for dotfiles for all machines and then branches that branch off of that main like 'main.arch.MACHINE_NAME' that are merged like a waterfall during sync (main -[merge]-> main.arch -[merge]-> main.arch.MACHINE_NAME). (I can also cherry pick up the waterfall)

[1]: https://www.atlassian.com/git/tutorials/dotfiles [2]: https://gist.github.com/tionis/a0f23a7a33b0e289f1b03cc6ff503...

the ultimate bikeshedding with dotfiles is home-manager with nix, an infinite cacophony of deep pain and enlightened pleasure

Yes, I've gone through every style of dotfile management. Stow, bare git repo, custom script, and now nix with home-manager. Using Nix is definitely the best solution so far, largely because not only does it manage the configurations, but also installs the programs you need.

Plus, Nix allows for installing the same versions of those programs everywhere you're using Nix.

The one thing that makes me hesitate with nix is that it only really supports Linux and Darwin; of the BSDs only FreeBSD has any support (somewhat suboptimal still), and AIUI Windows is also unsupported.

I'm using yadm for some years now, which works really well:

https://github.com/TheLocehiliosan/yadm

I’ve tried a bunch of these out and settled on yadm as well. It’s basically a shim for Git that tracks your home directory with a bare repo stored elsewhere.

I use yadm too but I found the changes between versions a bit tricky. The upgrade scripts didn't quite work, although I did try to jump from v1 to v3

I use yadm too but I found the differences between versions a bit tricky. The upgrade scripts didn't quite work, although I did try to jump from v1 to v3

I highly recommend dotter, especially if your dotfiles have variation from machine to machine and or if you don't need all of them at a given time. It's pretty simple and lightweight

https://github.com/SuperCuber/dotter

I've had really good luck with vcsh and git-crypt. vcsh can be a little awkward to use because git commands need to be scoped to the vcsh project, but you get used to it. I like having separate git repos for separate roles (e.g., fish-common, fish-personal, fish-work). Then, depending on what I'm doing on a particular machine I can pull in just the roles I need. It may seem like overkill, but I've found it very helpful in sharing my dev config without pulling personal stuff onto a work machine, vice versa.

git-crypt allows me to protect sensitive files while still tracking them in a git repo. I don't think I'd rely on it for shared projects, but it works well for me.

> Submodules make managing dotfile dependencies so much easier.

I'm impressed by the dedication of anyone who has enough dotfile config to use a submodule!

I still like Vorta for dotfiles, just because it's trivial to set up and only uses tools I already use for other things. Most of the dotfiles I want to back up have secrets, so GitHub isn't really an option.

SyncThing seems like it could work well for dotfiles too, with some kind of frontend that copied stuff to a sync folder.

The good stuff: https://dotfiles.github.io/inspiration/

This one's my favorite - has been working reliably and with barely any intervention for years now: https://github.com/andsens/homeshick

My own dotfiles: https://github.com/epiccoleman/dotfiles

1. sudo apt/dnf/zypper install stow

2. man stow

3. git init ~/dotfiles

have at'er

Previous discussion: https://news.ycombinator.com/item?id=32632533 (256 points | Aug 28, 2022 | 61 comments)

Am I missing something or is the use of "GitHub" weird here? Are they GitHub employees? None of the creators seem associated with GitHub. They're _users_ of GitHub, nothing more.

I bet more than half developers do not differentiate between git and GitHub.

Just use your home folder as a git repo, rename .git, create alias "githome" to git cli pointing to that directory and viola, you have all you need.

What I see is a mishmash of information.

Is there a better resource you can recommend?

All you really need is one alias.

alias homegit="git --work-tree=$HOME --git-dir=$HOME/.dotfiles.git"

This seems overwhelming. A bunch of paths to go down. No clear recommendation.

Reply on news.ycombinator.com