Way to store your dotfiles: A bare Git repository (2016) • Hacker News Board

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

#21

Post by jaytaylor » Sat, Apr 06, 2019, 4:54 PM UTC

wrs wrote: post #16

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

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.com/a/15320746/293064

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

#22

Post by mikewhy » Sat, Apr 06, 2019, 4:54 PM UTC

yjftsjthsd-h wrote: post #6

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

I do the same! https://github.com/mikew/dotfiles/blob/master/install.sh#L26...

Although yours is more sound, I'm just moving files to `*.old`.

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

#23

Post by syoc » Sat, Apr 06, 2019, 5:03 PM UTC

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

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

#24

Post by johnchristopher » Sat, Apr 06, 2019, 5:09 PM UTC

syoc wrote: post #23

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

I don't know why you are being downvoted but I'd like to know. I have a very official and very governmental API that isn't properly set up and the official doc says to use curl -k to talk to it. I had a long argument with one of the dev, with a PoC and a live example, about how it was a bad idea, especially considering how it can easily be fixed but... the 'feature' is still there.

I suppose the next $2,000 a day consultant will get them the memo.

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

#25

Post by pmoriarty » Sat, Apr 06, 2019, 5:40 PM UTC

The problem with keeping all dotfiles in a single repo is that if you want to get an older version of one particular dotfile, you'll also be getting older versions of other dotfiles as well.

I want every dotfile I use to be independent of the rest and a log that shows changes to just that one dotfile, so I store each of them in separate repos and use GNU Stow[1] to manage them.

The above is actually a bit of an oversimplification of what I do, as I store related dotfiles in a single repo as well, so that (for example) all my weechat dotfiles are in a single repo, as I rarely want to checkout a single file independantly of the rest there.

[1] = https://www.gnu.org/software/stow/

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

#26

Post by benley » Sat, Apr 06, 2019, 5:48 PM UTC

pmoriarty wrote: post #25

The problem with keeping all dotfiles in a single repo is that if you want to get an older version of one particular dotfile, you'll also be getting older versions of other dotfiles as well. I want every dotfile I use to be independent of the rest and a log that shows changes to just that one dotfile, so I store each of them in separate repos and use GNU Stow[1] to manage them. The above is actually a bit of an overs…

> you want to get an older version of one particular dotfile, you'll also be getting older versions of other dotfiles as well.

That doesn't really follow; it is easy to check out old versions of a single file with git:

    git checkout

for ".bashrc from two commits ago on the current branch", that would be:

    git checkout HEAD~2 .bashrc

Hopefully I'm not just misunderstanding your point here.

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

#27

Post by bruxis » Sat, Apr 06, 2019, 5:48 PM UTC

pmoriarty wrote: post #25

The problem with keeping all dotfiles in a single repo is that if you want to get an older version of one particular dotfile, you'll also be getting older versions of other dotfiles as well. I want every dotfile I use to be independent of the rest and a log that shows changes to just that one dotfile, so I store each of them in separate repos and use GNU Stow[1] to manage them. The above is actually a bit of an overs…

This sounds like a somewhat uncommon use case to me, but wouldn't a simple git per-file checkout work here?

Something like:

  git checkout c3f2ab -- configs/.vimrc

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

#28

Post by boardwaalk » Sat, Apr 06, 2019, 5:52 PM UTC

pmoriarty wrote: post #25

The problem with keeping all dotfiles in a single repo is that if you want to get an older version of one particular dotfile, you'll also be getting older versions of other dotfiles as well. I want every dotfile I use to be independent of the rest and a log that shows changes to just that one dotfile, so I store each of them in separate repos and use GNU Stow[1] to manage them. The above is actually a bit of an overs…

Git can fetch a single file as of any commit with 'git show' and show the history of any single file with 'git log' or 'git diff'. Any decent web/GUI tool will do these things too.

A Git repo per small text file seems like overkill to me.

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

#29

Post by BluSyn » Sat, Apr 06, 2019, 5:53 PM UTC

syoc wrote: 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 be burned to the ground.

Normally when I see this I will manually download the bash script, read through exactly what it does, and manually type in each command instead of running the script directly. This way I know what it is doing, and it can't hide command output by piping into /dev/null and doing something without my knowledge.

Seriously people. Never. Trust. Bash Scripts.

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

#30

Post by djblue » Sat, Apr 06, 2019, 6:08 PM UTC

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?

The reason I want to be able to have different files for different machines was to make slight variations to some of my dotfiles. I used to use branches but it was too much error prone work keeping all my branches up-to-date. I switched to a system where I template my dotfiles, but now I have to expand those templates for them to actually work. I do have leverage when to expand the templates and how to install them. There are a bunch of different ways to do this depending on what you want but what I ended up doing was:

1. Template files using a syntax that was easy find / replace using a regex. You could use an existing one if you like.

2. Generate a bash install script with all the file variants embedded as base64 strings. I can build this script locally, but I also have a travis ci build that pushes up the install.sh script as a gh-pages like branch.

3. I can now curl the install.sh script from any machine I want and bootstrap my dotfiles. The only install time dependencies are bash, curl, git, base64, mkdir, and echo so it's a very portable self-contained script.

4. During install time, I use a case on hostname to determine which files to use and I use git to put them into my $HOME directory using a similar strategy described by the article.

github: https://github.com/djblue/dotfiles install.sh: https://git.io/vxQ4g