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 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.
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.
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.
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.
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.
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 "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.
(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)
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
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.
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.
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 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.
96 comments
[ 2.8 ms ] story [ 135 ms ] threadI 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
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.
http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...
Seems to be quite a common pattern: https://github.com/search?o=desc&q=dotfiles&s=stars&type=Rep...
https://github.com/jamescun/dotfiles
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.
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...
1: https://robots.thoughtbot.com/rcm-for-rc-files-in-dotfiles-r...
1. https://www.gnu.org/software/stow/
It's basically a dotfile manager. Symbolically links your stuff and runs scripts.
https://github.com/andreis/cfg
https://github.com/qznc/dot
https://github.com/riquito/configs
The usage is
Whenever I update the repository, maybe adding files, I run this in the other computers: which simply refresh the symlinks (I should remove stale symlinks now that I think about it, for removed configurations - never happened yet)