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

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

atlassian.com

Post reply on HN
Print view View original

11–20 of 60 posts

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

#11

Post by yjftsjthsd-h »

lwhsiao wrote: 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?

Why do you want different configs on different machines? I think the "easy" solution is "don't do that";) But of course that's useless advice if you actually have some usecase, so a suggestion: Have case/if blocks on $(hostname), or even do something like `test -f ~/dotfiles/bashrc.$(hostname).local && source ~/dotfiles/bashrc.$(hostname).local`

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

#12

Post by rudiv »

yjftsjthsd-h wrote: post #7
sametmax wrote: post #5

Earlier quoted context omitted.

I use stow. But honestly, I don't think it's better than git.

It's orthogonal, isn't it? You keep your dotfiles in a repo, then have stow "install" the checkout/clone thereof. EDIT: Also on stow - I tried it a couple times and it never seemed flexible enough. Can it handle things like keeping ~/.config/nvim and ~/.vim in the same stow directory? (And for that matter, can it link them together? I like having the same config for vim and neovim)

I just have both directories in my dotfiles repo and have the vim one symlinked to the nvim one. Admittedly I haven't fully explored the capabilities of stow, there might be a better way.

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

#13

Post by yjftsjthsd-h »

joombaga wrote: post #9
yjftsjthsd-h wrote: post #6

Earlier quoted context omitted.

I do almost exactly the same as you; my install.sh is a glorified wrapper around `ln -s`, but for each file, it verifies whether the file is already symlinked and if not renames the original to something like `.foo.bak.$(date -I)`. This is probably overkill, but it was especially nice when I was just starting to version control my dotfiles and still found unmanaged files sometimes that contained things worth saving.

Can you share?

Sure! https://gitlab.com/snippets/1844438

EDIT: Some quirks to note, especially if you want to steal this script: 1. I use ~/.local/etc as my dotfile directory. 2. I support multiple shells but have all of them use ~/.profile rather than shell-specific files (most config overlaps, and there's a case stmt that deals with per-shell settings). 3. The vim/neovim bit at the bottom will fail silently if the directory already exists; thankfully this is rare, but it should be fixed some time.

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

#14

Post by lscotte »

mikewhy wrote: post #2

Seems much more complicated compared to: git checkout https://github.com/my/dotfiles.git cd dotfiles # this is little more than `find . -maxdepth 1 -exec ln -sf {} ~/ \;` ./install How are others here managing their dotfiles?

I use a combination of stow and git via a script I wrote that I call stash - https://github.com/scotte/stash - it's very basic and simple, but has served me well.

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

#15

Post by katet »

lwhsiao wrote: 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 have a low-key solution. I check in files named by the hostname. For example `.bashrc.[hostname]`. Then I have a quick conditional in all my .bashrc files that checks for a hostname-specific file. This way, I commit them all, but only the relevant ones get loaded.

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

#16

Post by wrs »

minaguib wrote: 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…

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.)

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

#17

Post by jaytaylor »

minaguib wrote: 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 detecting when the OS is Linux or macOS within the scripts themselves and using an if statement to gate their execution or sourcing.

This concept is related to another HN personal favorite of mine: "Best thing in your bash_profile / aliases" [0]. Lots of interesting command-line shell optimization and slick hack ideas in there.

Thanks again for showing me a superior way :)

[0] https://news.ycombinator.com/item?id=18898523

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

#18

Post by frutiger »

lwhsiao wrote: 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?

This is overkill, but I have a DAG of profiles. Each profile can refer to one or more parent profiles. When I produce a config for a particular profile, a small Python script applies the profiles starting from the root node(s).

To avoid trashing my home directory, this actually is done to the side and committed into a bare git repository (this part is similar to the article). Afterwards, I use `git --git-dir=... --work-tree=~ checkout -p` to apply any changes one-by-one, allowing me to preserve any local edits I may have made.

All this is available as a sparsely documented Python package: https://github.com/frutiger/stratum

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

#20

Post by __blockcipher__ »

lwhsiao wrote: 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?

Check $uname and other variables with if statements to activate aliases depending on OS, username etc.

I also keep a barebones “core” of aliases/functions that i use everywhere (e.g. on linux servers as well as my current macos laptop). And then a file that contains the non-core stuff that only get used on my dev environment (MacBook) but not on servers.

—

It’d help if you provided examples of what differences you have between machines though. Most should be pretty simple e.g. slightly different dir structure, different package managers etc.

Post reply on HN