Live data from Hacker News

Dotfiles: Unofficial Guide to Dotfiles on GitHub

dotfiles.github.io

51–60 of 74 posts

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#51
post #45

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?

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#52
post #11

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.

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 w…

[deleted]

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#53
post #11

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.

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 w…

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

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#55

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.

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#56
post #11

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.

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,…

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.

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#57

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.

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.

Re: Dotfiles: Unofficial Guide to Dotfiles on GitHub

#60
post #51
post #45

Earlier quoted context omitted.

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.

Post reply on HN