All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
1 vcsh - manage config files in $HOME via fake bare git repositories
13 There are several ways to get in touch with the author and a small but committed
14 community around the general idea of version controlling your (digital) life.
16 * IRC: #vcs-home on irc.oftc.net
18 * Mailing list: http://lists.madduck.net/listinfo/vcs-home
20 * Pull requests or issues on https://github.com/RichiH/vcsh
24 vcsh allows you to have several git repositories, all maintaining their working
25 trees in $HOME without clobbering each other. That, in turn, means you can have
26 one repository per config set (zsh, vim, ssh, etc), picking and choosing which
27 configs you want to use on which machine.
29 vcsh was designed with [mr] [1] in mind so you might want to install that, as
32 Read INSTALL.md for detailed setup instructions.
34 The following overview will try to give you an idea of the use cases and
35 advantages of vcsh. See sections 3 and 4 for detailed instructions and
40 Some people found it useful to look at slides and videos explaining how vcsh works.
41 They can all be found at [here](http://richardhartmann.de/talks/).
45 ## 3.1 Comparison to Other Solutions ##
47 Most people who decide to put their dotfiles under version control start with a
48 **single repository in $HOME**, adding all their dotfiles (and possibly more)
49 to it. This works, of course, but can become a nuisance as soon as you try to
50 manage more than one host.
52 The next logical step is to create single-purpose repositories in, for example,
53 ~/.dotfiles and to create **symbolic links in $HOME**. This gives you the
54 flexibility to check out only certain repositories on different hosts. The
55 downsides of this approach are the necessary manual steps of cloning and
56 symlinking the individual repositories. It will probably become a nuisance when
57 you try to manage more than two hosts.
59 **vcsh** takes this second approach one step further. It expects
60 **single-purpose repositories** and stores them in a hidden directory (similar
61 to ~/.dotfiles). However, it does not create symbolic links in $HOME; it puts
62 the **actual files right into $HOME**.
64 Furthermore, by making use of [mr] [1], it makes it very easy to enable/disable
65 and clone a large number of repositories. The use of mr is technically optional
66 (see 4.3), but it will be an integral part of the proposed system that follows.
68 ## 3.2 Default Directory Layout ##
70 To illustrate, this is what a possible directory structure looks like.
73 |-- $XDG_CONFIG_HOME (defaults to $HOME/.config)
77 | | | |-- gitconfigs.vcsh
79 | | | |-- offlineimap.vcsh
83 | | | |-- vimperator.vcsh
84 | | | `-- snippets.git
86 | | |-- zsh.vcsh -> ../available.d/zsh.vcsh
87 | | |-- gitconfigs.vcsh -> ../available.d/gitconfigs.vcsh
88 | | |-- tmux.vcsh -> ../available.d/tmux.vcsh
89 | | `-- vim.vcsh -> ../available.d/vim.vcsh
93 | |-- zsh.git -----------+
94 | |-- gitconfigs.git |
98 |-- .zshrc <----------------------+
106 The files you see in $XDG\_CONFIG\_HOME/mr/available.d are mr configuration files
107 that contain the commands to manage (checkout, update etc.) a single
108 repository. vcsh repo configs end in .vcsh, git configs end in .git, etc. This
109 is optional and your preference. For example, this is what a zsh.vcsh
110 with read-only access to my zshrc repo looks likes. I.e. in this specific
111 example, push can not work as you will be using the author's repository. This
112 is for demonstration, only. Of course, you are more than welcome to clone from
113 this repository and fork your own.
115 [$XDG_CONFIG_HOME/vcsh/repo.d/zsh.git]
116 checkout = vcsh clone 'git://github.com/RichiH/zshrc.git' $MR_REPO
117 push = echo "Cannot push to read-only repo" >&2
118 #status = vcsh run $MR_REPO git $MR_ACTION
119 #commit = vcsh run $MR_REPO git $MR_ACTION
120 #gc = vcsh run $MR_REPO git $MR_ACTION
122 The commented lines are only necessary if you are using `mr` prior to version
123 1.11. Starting with this version, `vcsh` support is properly integrated.
127 $XDG\_CONFIG\_HOME/mr/available.d contains *all available* repositories. Only
128 files/links present in mr/config.d, however, will be used by mr. That means
129 that in this example, only the zsh, gitconfigs, tmux and vim repositories will
130 be checked out. A simple `mr update` run in $HOME will clone or update those
131 four repositories listed in config.d.
135 Finally, ~/.mrconfig will tie together all those single files which will allow
136 you to conveniently run `mr up` etc. to manage all repositories. It looks like
141 # The following line is only needed if your mr does not have vcsh support
142 # in core, that is version 1.10 or older. Check the file itself if you are
144 include = cat /usr/share/mr/vcsh
145 # Include all (enabled) configuration snippets (see above)
146 include = cat ${XDG_CONFIG_HOME:-$HOME/.config}/mr/config.d/*
150 $XDG\_CONFIG\_HOME/vcsh/repo.d is the directory where all git repositories which
151 are under vcsh's control are located. Since their working trees are configured
152 to be in $HOME, the files contained in those repositories will be put in $HOME
154 Of course, [mr] [1] will work with this layout if configured according to this
155 document (see above).
157 vcsh will check if any file it would want to create exists. If it exists, vcsh
158 will throw a warning and exit. Move away your old config and try again.
159 Optionally, merge your local and your global configs afterwards and push with
160 `vcsh run foo git push`.
162 ## 3.3 Moving into a New Host ##
164 To illustrate further, the following steps could move your desired
165 configuration to a new host.
167 1. Clone the mr repository (containing available.d, config.d etc.); for
168 example: `vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr`
169 2. Choose your repositories by linking them in config.d (or go with the default
170 you may have already configured by adding symlinks to git).
171 3. Make sure the line 'include = cat /usr/share/mr/vcsh' in .mrconfig points
172 to an existing file. Check the file itself to see if the line is necessary.
173 4. Run mr to clone the repositories: `cd; mr update`.
176 Hopefully the above could help explain how this approach saves time by
178 1. making it easy to manage, clone and update a large number of repositories
180 2. making it unnecessary to create symbolic links in $HOME (thanks to vcsh).
182 If you want to give vcsh a try, follow the instructions below.
184 # 4 Getting Started #
186 Below, you will find a few different methods for setting up vcsh:
189 2. The Steal-from-Template Way
192 ### 4.1 The Template Way ###
194 #### 4.1.1 Prerequisites ####
196 Make sure none of the following files and directories exist for your test
197 (user). If they do, move them away for now:
201 * $XDG\_CONFIG\_HOME/mr/available.d/mr.vcsh
202 * $XDG\_CONFIG\_HOME/mr/available.d/zsh.vcsh
203 * $XDG\_CONFIG\_HOME/mr/config.d/mr.vcsh
204 * $XDG\_CONFIG\_HOME/vcsh/repo.d/mr.git/
206 All of the files are part of the template repository, the directory is where
207 the template will be stored.
211 #### 4.1.2 Install vcsh ####
213 #### 4.1.2.1 Debian ####
215 If you are using Debian Squeeze, you will need to enable backports
219 #### 4.1.2.2 Arch Linux ####
221 vcsh is availabe via [AUR](https://aur.archlinux.org/packages.php?ID=54164)
222 and further documentation about the use of AUR is available
223 [on Arch's wiki](https://wiki.archlinux.org/index.php/Arch_User_Repository).
226 wget https://aur.archlinux.org/packages/vc/vcsh-git/vcsh-git.tar.gz
227 tar xfz vcsh-git.tar.gz
230 pacman -U vcsh*.pkg.tar.xz
232 #### 4.1.2.3 From source ####
234 If your version of mr is older than version 1.07, make sure to put
236 include = cat /usr/share/mr/vcsh
238 into your .mrconfig .
240 # choose a location for your checkout
243 git clone git://github.com/RichiH/vcsh.git
245 ln -s vcsh /usr/local/bin # or add it to your PATH
248 #### 4.1.3 Clone the Template ####
250 vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
252 #### 4.1.4 Enable Your Test Repository ####
255 mv ~/.zshrc ~/zshrc.bak
256 cd $XDG_CONFIG_HOME/mr/config.d/
257 ln -s ../available.d/zsh.vcsh . # link, and thereby enable, the zsh repository
261 #### 4.1.5 Set Up Your Own Repositories ####
263 Now, it's time to edit the template config and fill it with your own remotes:
265 vim $XDG_CONFIG_HOME/mr/available.d/mr.vcsh
266 vim $XDG_CONFIG_HOME/mr/available.d/zsh.vcsh
268 And then create your own stuff:
271 vcsh run foo git add -f bar baz quux
272 vcsh run foo git remote add origin git://quuux
273 vcsh run foo git commit
274 vcsh run foo git push
276 cp $XDG_CONFIG_HOME/mr/available.d/mr.vcsh $XDG_CONFIG_HOME/mr/available.d/foo.vcsh
277 vim $XDG_CONFIG_HOME/mr/available.d/foo.vcsh # add your own repo
281 ### 4.2 The Steal-from-Template Way ###
283 You're welcome to clone the example repository:
285 vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
286 # make sure 'include = cat /usr/share/mr/vcsh' points to an exiting file
289 Look around in the clone. It should be reasonably simple to understand. If not,
290 poke me, RichiH, on Freenode (query) or OFTC (#vcs-home).
293 ### 4.3 The Manual Way ###
295 This is how my old setup procedure looked like. Adapt it to your own style or
296 copy mine verbatim, either is fine.
302 # Clone vcsh and make it available
303 git clone git://github.com/RichiH/vcsh.git vcsh
304 sudo ln -s ~/work/git/vcsh/vcsh /usr/bin/local
307 Grab my mr config. see below for details on how I set this up
309 vcsh clone ssh://<remote>/mr.git
310 cd $XDG_CONFIG_HOME/mr/config.d/
311 ln -s ../available.d/* .
314 mr is used to actually retrieve configs, etc
318 # adapt /usr/share/mr/vcsh to your system if needed
319 include = cat /usr/share/mr/vcsh
320 include = cat $XDG_CONFIG_HOME/mr/config.d/*
321 ~ % echo $XDG_CONFIG_HOME
323 ~ % ls $XDG_CONFIG_HOME/mr/available.d # random selection of my repos
324 git-annex gitk.vcsh git.vcsh ikiwiki mr.vcsh reportbug.vcsh snippets.git wget.vcsh zsh.vcsh
326 # then simply ln -s whatever you want on your local machine from
327 # $XDG_CONFIG_HOME/mr/available.d to $XDG_CONFIG_HOME/mr/config.d
333 ### 5.1 Keeping repositories Up-to-Date ###
335 This is the beauty of it all. Once you are set up, just run:
342 ### 5.1 Making Changes ###
344 After you have made some changes, for which you would normally use `git add`
345 and `git commit`, use the vcsh wrapper (like above):
347 vcsh run foo git add -f bar baz quux
348 vcsh run foo git commit
349 vcsh run foo git push
351 By the way, you'll have to use -f/--force flag with git-add because all files
352 will be ignored by default. This is to show you only useful output when running
353 git-status. A fix for this problem is being worked on.
355 ### 5.3 Using vcsh without mr ###
357 vcsh encourages you to use [mr] [1]. It helps you manage a large number of
358 repositories by running the necessary vcsh commands for you. You may choose not
359 to use mr, in which case you will have to run those commands manually or by
362 #### A Few Examples ####
364 To initialize a new repository: `vcsh init zsh`
366 To clone a repository: `vcsh clone ssh://<remote>/zsh.git`
368 To interact with a repository, use the regular Git commands, but prepend them
369 with `vcsh run $repository_name`. For example:
371 vcsh run zsh git status
372 vcsh run zsh git add -f .zshrc
373 vcsh run zsh git commit
375 Obviously, without mr keeping repositories up-to-date, it will have to be done
376 manually. Alternatively, you could try something like this:
378 for repo in `vcsh list`; do
379 vcsh run $repo git pull;
384 mr can be found at: [http://kitenet.net/~joey/code/mr/][1]
386 [1]: http://kitenet.net/~joey/code/mr/ (http://kitenet.net/~joey/code/mr/)