Shared publicly  - 
 
Interesting post from one of the top contributors in Git on Stack Overflow: +Amber Yust. (http://stackoverflow.com/tags/git/topusers)  

I like the idea of having your dotfiles versioned in a subdirectory of your homedir.
That could mean symlinking your dotfiles to that subdir, but in this SO question (http://stackoverflow.com/a/11787448/6309), you have a reference to (http://barzilay.org/) Eli Barzilay's comment (http://www.xxeo.com/archives/2010/02/16/dotfiles-in-git-finally-did-it.html#li-comment-126903), which I find interesting:

- either make your home a git repository,
- or use symlinks to the actual repository.

Eli adds:

I dislike the first for the usual reasons: more than the problem of seeing your whole world as untracked files without setting a default, there’s a more serious problem of your home directory being an actual git repo. What if you run some git command expecting it to do something except you’re not in the right directory? Usually, this will be an error (unless you’re in a different repo), but now this is guaranteed to be a mess.

OTOH, I dislike the symlink approach for more than just the minor hassle of a one-line script that creates the symlinks… What if some program updates a file by replacing the existing one?  
In that situation not only will it break the link to the repo and you won’t see the change, but as an added bonus the usual careless one-liner that creates symlinks will overwrite the replaced file with the previous contents therefore evaporating the new contents.  
Another problem: what if you want things to work reasonably well on cygwin, where symlinks are not really visible as such to native windows programs?

So I’ve finally found a solution that takes the best of both:  
put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory.  
Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case.  
You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
1
Amber Yust's profile photoDan VonC's profile photoNicolas Correard's profile photo
6 comments
 
Yeah, the only downside of the worktree solution is the one I mentioned in my post about not knowing whether a given dotfile is tracked or not at quick glance.
 
how about rsyncing everything regularly instead of using symlinks? (and then this cron job could also automatically add and commit?). just a thought.
 
+Nicolas Correard a/ I don't recommend symlinks. b/ the goal here is to build an history of changes, not just to backup changes. Hence a VCS (Version Control System) like git.
 
+Daniel Chaffiol I don't think +Nicolas Correard is suggesting using rsync instead of git; it seems he's more just suggesting using it instead of an external worktree and/or symlinks.
 
+Amber Yust I wouldn't trust an extra step (rsync) in order to build an history. I would rather build an history directly from the actual files (referenced by the external worktree), not some rsync'ed somewhere else.
 
+Amber Yust that's what I meant, thanks. +Daniel Chaffiol I was thinking along a backup/replication that would still keep history in git. But your "core.worktree" solution would work nicely to solve both of the points you mention. Just one thing: why not use .gitignore instead of .git/info/exclude? If the local repo gets wiped out for some reason, it'd be nice to have the .gitignore restored (and also follow the history of which dot file one decided to ignore).
Add a comment...