Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unofficial guide to dotfiles on GitHub

dotfiles.github.io

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Unofficial guide to dotfiles on GitHub

#51

Post by CrystalCuckoo »

MereInterest wrote: post #5
jbaber wrote: post #2

[This] way (linked from the tutorials section of the page) is a great way to version your dotfiles without symlinks or installer scripts. [This]: https://www.atlassian.com/git/tutorials/dotfiles

What issue do symlinks have that makes them worth listing as a negative? Asking as someone who wrote an installer script to make symlinks a decade ago, and has used it whenever setting up a new computer ever since.

Enabling/disabling systemd services is done via managing symlinks. Unfortunately, when disabling a service in systemd, it follows and remove symlinks which can remove your symlinked service files.

Re: Unofficial guide to dotfiles on GitHub

#52

Post by allendoerfer »

Aarvay wrote: post #45

Just wanted to mention Stow[1] here, which I use to symlink my dotfiles on a new machine on a per app basis for many years now. My set up script just installs basic compiler toolchain and runs a bunch of stow commands based on Linux/Mac OS. I also adhere to XDG base spec[2] so I can keep my ~/ clean. 1: https://www.gnu.org/software/stow/ 2: https://wiki.archlinux.org/title/XDG_Base_Directory

I do not like comments, which are basically upvotes, but yes, Stow is the answer and this should be the top comment.

Re: Unofficial guide to dotfiles on GitHub

#54

Post by azemetre »

okasaki wrote: post #41

There are so many utilities. Why not just use ansible? It can manage your dotfiles and much more (you can configure your whole machine).

I’m slowly trying to make ansible playbook that pulls in my dot files and installs everything I need (node, rust, go, all my CLTs, etc).

Re: Unofficial guide to dotfiles on GitHub

#55

Post by bengalister »

okasaki wrote: post #41

There are so many utilities. Why not just use ansible? It can manage your dotfiles and much more (you can configure your whole machine).

I used to manage my dotfiles with stow (xstow actually) and do some simple links. Now I run an Ansible playbook that creates links or copy depending on the files and also install tools on different OSes.

The big benefit is that it can be organized in a modular way with roles and tags, and sensitives files (like my gpg keys...) can be encrypted with the vault.

Re: Unofficial guide to dotfiles on GitHub

#56

Post by jacobmischka »

gorgoiler wrote: post #31

It took me 20 years to have an important realization about version controlled dotfiles: what I wanted to do was manage a set of sensible, personalized, non-standard behaviours for each tool I used, and have a way of distributing those across systems. What I didn’t need at all, after all, was anything that installed different things on different hosts or classes of hosts. Luckily, every tool I want to configure has a…

I do something similar, though I use the "defaults" as the starting point and add overrides in local files which aren't checked in. Something like this:

    # .dotfiles/.bashrc
    # shared baseline config...
    if [ -f ~/.bashrc.local ]; then
        . ~/.bashrc.local
    fi

Re: Unofficial guide to dotfiles on GitHub

#57

Post by rovr138 »

Aarvay wrote: post #45

Just wanted to mention Stow[1] here, which I use to symlink my dotfiles on a new machine on a per app basis for many years now. My set up script just installs basic compiler toolchain and runs a bunch of stow commands based on Linux/Mac OS. I also adhere to XDG base spec[2] so I can keep my ~/ clean. 1: https://www.gnu.org/software/stow/ 2: https://wiki.archlinux.org/title/XDG_Base_Directory

I really like stow. It handles almost everything for me.

One thing, I didn't split things by apps per se. I split them based on task. In some machines, I do Python work, so I created a 'python' package. In some I do PHP, so I created a 'php' one. I have a 'base' one where it has my .bashrc, .profile, .bash_profile, fish configs and other things.

Everything in the .bashrc. .profile, etc is loaded around conditionals. So, while the files are long, the section only activates if the other package is available. I thought about splitting it onto files, but most editors have a way of collapsing sections, so I decided to keep it on one so it's easy to edit in one place.

Re: Unofficial guide to dotfiles on GitHub

#59

Post by wseqyrku »

Not much work ou-of-the-box.

In the home directory (~) run:

  git init
  git remote add origin https://github.com/username/dotfiles
  echo '/**' >> .gitignore;
  git add -f .gitignore
  git add -f .gitconfig
  git add -f .bash_profile
  # etc and push
On the second machine:

  git clone https://github.com/username/dotfiles tmp --no-checkout
  mv tmp/.git .
  rmdir tmp 
  git reset --mixed

Re: Unofficial guide to dotfiles on GitHub

#60

Post by OJFord »

gorgoiler wrote: post #31

It took me 20 years to have an important realization about version controlled dotfiles: what I wanted to do was manage a set of sensible, personalized, non-standard behaviours for each tool I used, and have a way of distributing those across systems. What I didn’t need at all, after all, was anything that installed different things on different hosts or classes of hosts. Luckily, every tool I want to configure has a…

I still want the versioning of host-specific stuff though, as well as the backup (by having the repo on GitHub too), and easy reference to other hosts' config that I might want on my current one after all (or setting it up for the first time).

I do this by having ~/.config/tool/blah.conf as you'd expect; but also ~/.config/by-host/$hostname/tool/blah.conf

I agree 'classes of hosts' is way overkill for probably anyone's personal machines though. Only thing close to that I do is with aconfmgr for more system-oriented stuff - but that's all simply on the basis 'if SSD enable TRIM' type 'classes', no manual specification.

Post reply on HN