git init --bare $HOME/.myconf
alias config='/usr/bin/git --git-dir=$HOME/.myconf/ --work-tree=$HOME'
config config status.showUntrackedFiles no
where my ~/.myconf directory is a git bare repository. Then any file within the home folder can be versioned with normal commands like: config status
config add .vimrc
config commit -m "Add vimrc"
config add .config/redshift.conf
config commit -m "Add redshift config"
config push
And so one…No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.
Anyway it's the proper root for config files, since if you use a .config directory (as seems to be the modern choice) that needs to live in your home directory of course.
git clone --separate-git-dir=~/.myconf /path/to/repo ~
This is the best solution I've seen so far, and I may adopt it next time I get the itch to reconfigure my environment. git clone --separate-git-dir=$HOME/.myconf /path/to/repo $HOME/myconf-tmp
cp ~/myconf-tmp/.gitmodules ~ # If you use Git submodules
rm -r ~/myconf-tmp/
alias config='/usr/bin/git --git-dir=$HOME/.myconf/ --work-tree=$HOME'
and then proceed as before.I use ansible, to template my gitconfig for different unix machines, and to install software that might be referenced in a dotfile
https://github.com/berdario/dotfiles/blob/master/setup/roles...
https://github.com/berdario/dotfiles/blob/master/setup/feynm...
(I have a separate branch for windows, but I found out that branches are not a good solution for this, since unlike feature branches, they'll never be truly merged... and unlike maintainance branches, they'll never stop being touched due to being out of maintanance)
And I use my own script, to also support Windows (since ansible supports windows targets, but cannot be used from Windows)... I defined this table with the destination for the symlinks (or, in the case of .ghci the destination where to copy it, since symlinking it wouldn't work)
https://github.com/berdario/dotfiles/blob/master/deploy.py#L...
http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...
It helps weed out the crap I've accumulated since the last machine rebuild, and makes sure I don't end up with an ever-growing hairball of dotfile madness.
1: https://robots.thoughtbot.com/rcm-for-rc-files-in-dotfiles-r...
#!/usr/bin/env bash
#Read the keep directories from xstow.ini
ini="$(<'xstow.ini')"
IFS=$'\n' && ini=( ${ini} )
ini=( ${ini[*]/\ =/=} ) # remove tabs before =
ini=( ${ini[*]/=\ /=} ) # remove tabs after =
ini=( ${ini[*]/\ =\ /=} ) # remove anything with a space around =
#for each keep dir make sure it exists in the home dir
for i in ${ini[@]}
do
if [[ $i =~ ^\ *dir ]]
then
eval $i
mkdir $dir
fi
doneI keep my emacs init in org and I can't believe I've never thought of this.
https://github.com/skx/dotfiles/tree/master/.emacs.d
In there you'll find ~/.emacs/init.el which parses ~/.emacs/init.md which is a markdown file containing both documentation and executable Lisp.
There are other files in separate directories/packages, but I like the idea of placing everything in one readable file:
https://github.com/skx/dotfiles/blob/master/.emacs.d/init.md
** Meta
If you place the following code into your emacs init when saving the
~/.dotfiles.org file the dotfiles will all be exported.
#+BEGIN_SRC emacs-lisp :tangle yes
(defun dotfiles-hook ()
"If the current buffer is '~/.dotfiles.org' the code-blocks are
tangled."
(when (equal (buffer-file-name)
(expand-file-name (concat (getenv "HOME")
"/.dotfiles.org")))
(org-babel-tangle)))
(add-hook 'after-save-hook 'dotfiles-hook)
#+END_SRC
** bashrc
#+BEGIN_SRC conf :tangle ~/.bashrc
export PATH=$HOME/bin:$PATH
#+END_SRC
** tmux
#+BEGIN_SRC conf :tangle ~/.tmux.conf
unbind C-b
set -g prefix C-t
bind C-t send-prefix
#+END_SRC1. I run emacs-server, so the init file is run only during restarts OR when I manually load it from emacsclient.
2. Re-exporting all dotfiles seems rather redundant. I prefer to selectively export individual dotfiles only when I have made changes to it. That's why I was interested in the 'deploy' part.
I am not familiar enough with Babel, but it definitely seems to offer a more centralized way of managing my dotfiles. It's going into TODO.
I have a lot to say on the subject.
1. Like other users here, git is a great way version your files. Not just that, it handles the issue you have with keeping the configs of various systems in sync.
1b. It doesn't have to be GitHub, but understand pushing to some remote gives you a backup, and a way to keep the latest configs you have in sync across multiple machines.
2. As a rule of thumb, the more POSIX compliant you are, the more cross-compatible your dot-configs will be. In my case, a great deal of my config works superbly across Ubuntu, FreeBSD and OS X with no modification whatsoever.
3. dotfiles (https://pypi.python.org/pypi/dotfiles) is very helpful for building those initial symlinks.
4. Tangentially related is PATH's. Definitely be sure you're not accidentally appending multiple one's over again or omitting ones you want to search. For this, I recommend a pathappend function like one used at http://superuser.com/a/753948.
5. As for managing vim / neovim, I'm coming to the realization the amount of time I've spent trying to configure completion / fix tiny things over the years probably makes me lose the net benefit vim has given me. Too bad there is no intellij for the CLI. In any event, I keep a vim config at https://github.com/tony/vim-config which I document extensively. It has quite a lot of bells and whistles, but lazy loads and checks the system before installing certain plugins. It should work with neovim too.
I keep my central dot-configs (along with its submodules) at https://github.com/tony/.dot-config. Its permissively licensed, so feel free to copy whatever you'd like.
It needs to be sourced in .{bash,z}shrc and has features like tracking files from multiple repos (so called "castles"), auto-linking, auto-update every X days.
We also use it in our dev team to share some config (and ~/bin) files, works fine.
I want to avoid vendor lock-in to something like chef for this. The idea is that everything is either defined in a tool-agnostic config file, and bootstrapping / installing / updating the dependencies is handled by simple shell scripts. Down the road I can always swap out the tooling (bower, config_curator, archutil) without updating code in my repos since state is defined as data.
I don't like syslinks or putting ~/ under git as I don't want my working tree to affect my dotfiles until I run an "install" command.
https://github.com/riquito/configs
The usage is
git clone git@github.com:username/configs.git ~/.myconfigs
cd ~/.myconfigs
./reinstall.sh
Whenever I update the repository, maybe adding files, I run this in the other computers: cd ~/.myconfigs
git pull --ff-only
./reinstall.sh
which simply refresh the symlinks (I should remove stale symlinks now that I think about it, for removed configurations - never happened yet)Seems to be quite a common pattern: https://github.com/search?o=desc&q=dotfiles&s=stars&type=Rep...
I was previously using an automated Ruby script but found it inflexible and so have switched to a hand coded Makefile.
And I have dotfiles repository at GitHub. Some files are hosted in Dropbox (for API keys and etc.).
my dotfiles:
I also interviewed the developer some years ago here: http://episodes.gitminutes.com/2013/06/gitminutes-13-richard...
It's basically a dotfile manager. Symbolically links your stuff and runs scripts.
cd ~
git init
git remote add origin https://sgtpep@github.com/sgtpep/dotfiles.git
git fetch
git checkout -ft origin/master
git config status.showUntrackedFiles noIt is a very simple system for keeping your dotfiles (and other files) in Git.
cd ~
git init
And add this to a .gitignore: # Ignore everything
*
# Except the dotfiles I explicitely want to share
!.vimrc
!.tmux.conf
# ...