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.
For posterity, note that this will fail if your home directory isn't empty. To get around that, clone the repo's working directory into a temporary directory first and then delete that directory,
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'
Working on it! I'll give you full credit for it and link to this thread for reference. Also let me know if you have a Twitter account you'd like me to reference.
Nice thanks. I don't have twitter. Also don't present me as the inventor of this technique because I'm not. I've read this long time ago on some dark corners of the internet :-) I'm just pointing it out.
Honestly this is genius! I hadn't thought of doing it like that, thank you! I had resorted to the usual .cfg folder and a helper script to link/update everything.
Could you explain how this works? Won't this be putting the .bashrc in $HOME/.myconf/.bashrc, which won't get picked up by bash? (And similar for other dotfiles)
No, since the config alias runs git with the option "--work-tree=$HOME", which tells it that the working directory is your home directory root, i.e. where config files (used to) live.
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.
I have a "master" branch, and some "computer" branches. When changes are required for all computer, I do it in "master", and then update each branch by doing a "git merge master".
Not at all. You can 'git add' (or in the case of the technique above 'config add') only the files and folders that are safely stored in a repository. Because of the 'ShowUntrackedFiles' flag, git/config won't always show folders you don't want to track, which would be annoying.
It's because we specify to git that the working tree is the home folder. For it the versionning doesn't happen in ".myconf", but directly in the home folder
(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)
I do love stow. My only hurdle (and it's not unique to stow is the chicken-and-egg of a 'setup.sh' that builds out my Mac the way I like (creating directories, installing packages etc), when my SSH keys are in stow's SSH folder.
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.
I think no one has mentioned rcm[1]. I just maintain a private git repository cloned in .dotfiles in each system I own, and use rcm to set up symbolic links properly. It works pretty well with directories and lets you choose between creating and populating it with symlinks, or just symlinking the whole directory. For example, I can symlink the full .vim directory (including git submodules) and only link some files inside the .ssh directory (link the config file to my .dotfiles repo but leave ssh keys alone).
I've tried the other ones, but rcm is by far the most user friendly. I maintain a public and a private repo, and link them both into rcm. It works wonderfully.
Git and Xstow. I have a small shell script that parses the xstow.ini file and creates all the directories I have listed under the [keep-dirs] directive in order to prevent it from deleting empty directories or replacing them with links.
#!/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
done
Emacs Org-mode's org-babel functionality. I have a few org-mode files storing all the dotfiles, put under version control. I can update and deploy them from within Emacs.
This is the most interesting system I've heard about for dotfiles. How do you organize the org files? Having a single org file with all my dotfiles in it could be interesting but probably unwieldy. It could be interesting to use code block expansion for keeping secrets out of the dotfile source.
I keep my emacs init in org and I can't believe I've never thought of this.
This is what I came up with over lunch. I'm going to try keeping all my dotfiles in one org file. I have an init hook that runs org-bable-tangle to re-export all the dotfiles after saving.
** 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_SRC
Thanks. Upvoted your solution, but I see some problems with this approach for my workflow:
1. 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've probably spent hundreds of hours across all my configs over the years. In the old days, I'd rsync config files manually. Having frustrating times where I had to start everything over again.
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.
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.
I have everything in ~/dotfiles which is a git repository here: https://github.com/dmarcoux/dotfiles. Basically, I use GNU Stow to symlink what I need. I have master which contains common config and one branch per computer. Everything is explained in the README, in more details if you want do know more. It's not perfect yet, I still have some small irritants, but I'm quite happy with this setup.
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 have a modular family of git repos with a 'dotfiles' one that pulls in the dependencies via bower and handles various bootstrapping and install steps. I also have one for my system config which works similarly. Vim, zsh, and tmux have their own standalone repos with one step install and updating scripts. They are written as normal plugins that load other plugins.
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.
I see a trend of people maintaining a GitHub repo called `dotfiles` for their public configurations, myself included for zsh/tmux/vim/git. I haven't found a satisfactory way to sync secrets between machines other than via sneakernet.
I keep all my dotfiles in a repo at ~/cfg, and have a script to perform tasks such as creating symlinks (e.g. ~/.emacs.el -> ~/cfg/emacs.el) and installing brew, antigen, etc.
Just git and Github.I have two folders, a .dotfiles (https://github.com/Arc0re/dotfiles) that contains stuff like .emacs (for each OS), .bashrc/.zshrc, etc, which I symlink into my $HOME folder, and an elisp (https://github.com/Arc0re/mac-elisp) folder that contains my Emacs themes and plugins.
Thank you so much for that post! I used it extensively when I set up vcsh and my. It took a few hours to get everything working, but the flexibility is unbelievable.
There's a fork called homeshick which is a plain-bash rewrite of homesick, so it doesn't have the ruby dependencies (for those who care about that). There might be few differences, though.
I a Syncthing directory called "Data/" where my personal files are. Then I have a script which creates symlinks between ~/.dir and Sync/Data/dir and that's it, simple but works.
Payday loans are fleeting cash propels intended to get you through to the following payday. You round out an application giving data about yourself and your salary online for moment endorsement http://www.1monthloan-uk.co.uk/. Once affirmed, a cash development is kept into your financial records the next day. The loan organization will charge installment from your financial records on your next payday.
tar, scp, and a VPS server I've had for longer than I can remember (it's still running Lenny, if that helps -- its OpenSSL was too old to be vulnerable to Heartbleed...). Every new install, I scp the tarball and extract it to my home directory.
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.