Live data from Hacker News

Way to store your dotfiles: A bare Git repository (2016)

atlassian.com

41–50 of 60 posts

Re: Way to store your dotfiles: A bare Git repository (2016)

#41
post #3

I'm still looking for a good way to I'm using this approach, but looking for a way manage dotfiles for multiple machines. Having separate branches feels clunky, since there is a lot of overlap and tweak may involve making the same tweak on several branches. Any recommendations for managing this situation?

Surprised nobody has mentioned YADM - it can do per-device files and/or per-device templating too (jinja2 syntax). It's just a thin wrapper around git so you can use any git commands too.

http://yadm.io

Re: Way to store your dotfiles: A bare Git repository (2016)

#42
post #29
post #23

I don't understand how the curl http://site.com | bash anti-pattern has become so widespread. Especially with -k.

It originated as a way for people who aren't familiar with CLI to install things. People have now been trained to expect this level of simplicity. I've worked with people that will blindly copy and paste these lines into terminals, having absolutely no idea what they do, and even blindly type in sudo password when prompted. It's basically the worst of all worlds from a security perspective. In my opinion this should…

Downloading and reading the bash script isn't a solution either. Even if it isn't deliberately malicious, those things usually want to just puke files into some arbitrary corner of your system or homedir - really the author just made a "works fine on my system" crutch rather than doing the actual work of packaging. Then to double down, they'll often add some "clever" hooks to self-auto-update your local junkheap from their git nightly, because releasing deliberate versions doesn't "move fast and break enough things".

I either want to pull from the standard distribution repositories and rely on things updating automatically, compile from source tarballs with explicit version numbers, or at the very worst have a path-independent binary tarball that can be unpacked anywhere. If you can't manage any of these, then your project simply isn't ready for general availability.

Re: Way to store your dotfiles: A bare Git repository (2016)

#43
post #3

I'm still looking for a good way to I'm using this approach, but looking for a way manage dotfiles for multiple machines. Having separate branches feels clunky, since there is a lot of overlap and tweak may involve making the same tweak on several branches. Any recommendations for managing this situation?

I ended up putting everything common into the master branch, and keep only the varying parts (not the common parts) in machine-specific branches. These are normally "include files" that end up in ~/.profile.d/, ~/.emacd.d/, etc.

I have to check out both the main branch and the machine-specific branch in separate directories, and use symlinks. OK by me, though; I don't set up a new workstation often.

Re: Way to store your dotfiles: A bare Git repository (2016)

#44
post #3

I'm still looking for a good way to I'm using this approach, but looking for a way manage dotfiles for multiple machines. Having separate branches feels clunky, since there is a lot of overlap and tweak may involve making the same tweak on several branches. Any recommendations for managing this situation?

I template trees using a python script, for both ~ and /. The template language isn't even currently that complex - basic per-host conditionals suffice. The host pushing the config does the templating, serializes it, and shoves it over ssh to the receiver. This way I can do things like leave passwords in config files (eg mpd.conf) and not have them end up on eg a VPS. Another example is having helpful comments in authorized_hosts to say where a key is from without that information ending up on the hosts themselves.

The receiving host runs python, so it can do things like refuse to overwrite files that have been changed locally. I still need to add a notion of hooks to run on the receiver when a given file is changed. If the remote dependency on python/ssh becomes a problem, I will simply add an option to dump a tarball locally.

I really tried to use ansible et al, but those tools seem to be geared towards managing large groups of essentially identical hosts, rather than generally differing hosts with some commonality.

Re: Way to store your dotfiles: A bare Git repository (2016)

#46
post #16

Earlier quoted context omitted.

I think that method requires git to scan all the files in the directory so it can then ignore them. The advantage of the “showUntrackedFiles no” method is that git will only look at the tracked files, which is much faster if you have a million files in your home dir, like I do. (Or so I believe.)

I tried quickly looking into this to verify the claim, but haven't yet found anything to explain why this would be the case. Do you have any details about how or why git will scan everything in this case? I did find a pretty neat stack overflow post on the subject of gitignore whitelisting [0]. If we can get to the bottom of possible performance impact, would be cool to add the info there. [0] https://stackoverflow.c…

Without spending too much time on it, I think a cursory check shows git doing "the smart thing" with ignore rules.

  $ mkdir foo
  $ cd foo
  $ mkdir $(seq 1 1000)
  $ git init .
  $ strace -c git status
    On branch master

    No commits yet

    nothing to commit (create/copy files and use "git add" to track)
    % time     seconds  usecs/call     calls    errors syscall
    ------ ----------- ----------- --------- --------- ----------------
     75.97    0.058830          57      1035        15 openat
     16.48    0.012764           6      2002           getdents
      3.87    0.002999           3      1021           close
      2.91    0.002254           2      1022           fstat
      0.19    0.000147           8        18        14 lstat
      0.13    0.000100           4        24           read
      0.12    0.000092           6        16        12 stat
      0.09    0.000072           3        21        14 access
      0.06    0.000048          10         5           write
      0.04    0.000033          33         1           unlink
      0.03    0.000020           3         8           rt_sigaction
      0.02    0.000018           2        12           mprotect
      0.02    0.000015          15         1           munmap
      0.01    0.000010           3         4           getcwd
      0.01    0.000006           0        16           mmap
      0.01    0.000006           6         1           ioctl
      0.01    0.000005           2         3           brk
      0.01    0.000004           4         1           chdir
      0.00    0.000003           2         2           getpid
      0.00    0.000003           3         1         1 readlink
      0.00    0.000002           1         2           rt_sigprocmask
      0.00    0.000002           2         1           set_tid_address
      0.00    0.000002           2         1           set_robust_list
      0.00    0.000002           2         1           prlimit64
      0.00    0.000000           0         1           execve
      0.00    0.000000           0         1           arch_prctl
    ------ ----------- ----------- --------- --------- ----------------
    100.00    0.077437                  5221        56 total
Now let's add an ignore-all and check:

  $ echo "/*" > .gitignore
  $ strace -c git status
    On branch master

    No commits yet

    nothing to commit (create/copy files and use "git add" to track)
    % time     seconds  usecs/call     calls    errors syscall
    ------ ----------- ----------- --------- --------- ----------------
     46.25    0.000568         284         2           getdents
     16.78    0.000206           6        35        14 openat
      7.41    0.000091           6        16        12 stat
      7.17    0.000088           4        21        14 access
      5.62    0.000069           3        25           read
      4.72    0.000058           3        18        14 lstat
      4.15    0.000051           2        22           close
      2.93    0.000036          36         1           unlink
      2.28    0.000028           1        23           fstat
      0.81    0.000010           3         4           getcwd
      0.65    0.000008           1         8           rt_sigaction
      0.41    0.000005           5         1           ioctl
      0.33    0.000004           4         1           chdir
      0.24    0.000003           2         2           getpid
      0.24    0.000003           3         1         1 readlink
      0.00    0.000000           0         5           write
      0.00    0.000000           0        16           mmap
      0.00    0.000000           0        12           mprotect
      0.00    0.000000           0         1           munmap
      0.00    0.000000           0         3           brk
      0.00    0.000000           0         2           rt_sigprocmask
      0.00    0.000000           0         1           execve
      0.00    0.000000           0         1           arch_prctl
      0.00    0.000000           0         1           set_tid_address
      0.00    0.000000           0         1           set_robust_list
      0.00    0.000000           0         1           prlimit64
    ------ ----------- ----------- --------- --------- ----------------
    100.00    0.001228                   224        55 total

Re: Way to store your dotfiles: A bare Git repository (2016)

#47
post #4

I use something even simpler My dotfiles git repo is meant to be cloned in my home directory. It comes with this .gitignore committed in the repo: /* !/.vim/ /.vim/.netrwhist Basically it ignores everything in my home directory, unless I explicitly `git add` it, which matches my workflow. For the few cases where I want to notice changes (like the entire ~/.vim/ subdirectory), I explicitly un-ignore it as you can see…

You can use the `git check-ignore` command to check if a certain directory is ignored. I used it in my zsh config to suppress the status of ignored directories in my prompt.

Re: Way to store your dotfiles: A bare Git repository (2016)

#48
post #45

You need just 3 lines to start storing your dotfiles in git: cd ~ git init echo "*" >.git/info/exclude Enjoy!

Could you explain how this works/is meant to work?

You basically make your home dir a git repo and by default ignore everything inside it. When you want to store a dotfile in that repo, you have to force add it (`git add -f`) and it will be tracked.

You can learn more about how git ignores things here: https://git-scm.com/docs/gitignore

Re: Way to store your dotfiles: A bare Git repository (2016)

#49
post #3

I'm still looking for a good way to I'm using this approach, but looking for a way manage dotfiles for multiple machines. Having separate branches feels clunky, since there is a lot of overlap and tweak may involve making the same tweak on several branches. Any recommendations for managing this situation?

As others have mentioned, sourcing files based on hostname / uname might help:

    try-source () {
      if [ -f "$1" ]; then
        source "$1"
      fi
    }
    
    try-source "$HOME/.localrc.$(uname -s)"
    try-source "$HOME/.localrc.$HOSTNAME"
    try-source "$HOME/.localrc.$(uname -s).$HOSTNAME"

Re: Way to store your dotfiles: A bare Git repository (2016)

#50
post #4

I use something even simpler My dotfiles git repo is meant to be cloned in my home directory. It comes with this .gitignore committed in the repo: /* !/.vim/ /.vim/.netrwhist Basically it ignores everything in my home directory, unless I explicitly `git add` it, which matches my workflow. For the few cases where I want to notice changes (like the entire ~/.vim/ subdirectory), I explicitly un-ignore it as you can see…

That's clever, thanks for sharing this technique! In the past I wrote a bash setup script for my dotfiles repository which pretty much does the opposite, symlinking a combination of shared and os-specific directories and files into my home dirs. One definite advantage with your technique is that no special setup script is required. I'm thinking I can obviate the need for splitting ommon and os-specific dirs by just d…

i do the same (dotfiles with symlinking script) and it’s mostly great, but I’d recommend against os-specific switching in the scripts and files themselves. it’s the way i’d always done it previously but i switched to git-branch-per-system and it’s much better. the problems started when “chromebook linux” was different than “other laptop linux” and then “server linux” (not to mention os x) and there kept being more and more messy logic. separate git branches is way easier and has the benefit of a sort of “inheritance” of the shared stuff (branching and rebasing)
Post reply on HN