-vcsh - manage config files in $HOME via fake bare git repositories
+vcsh - Version Control System for $HOME (based on git)
+
# Index #
-1. Contact
-2. Introduction
-3. Overview
-4. Getting Started
-5. Usage
+1. [30 second howto](#30-second-howto)
+2. [Introduction](#introduction)
+3. [Overview](#overview)
+4. [Getting Started](#getting-started)
+5. [Usage](#usage)
+6. [Contact](#contact)
-# 1 Contact #
-There are several ways to get in touch with the author and a small but committed
-community around the general idea of version controlling your (digital) life.
+# 30 second howto #
-* IRC: #vcs-home on irc.oftc.net
+While it may appear that there's an overwhelming amount of documentation and
+while the explanation of the concepts behind `vcsh` needs to touch a few gory
+details of `git` internals, getting started with `vcsh` is extremely simple.
+
+Let's say you want to version control your `vim` configuration:
-* Mailing list: http://lists.madduck.net/listinfo/vcs-home
+ vcsh init vim
+ vcsh vim add ~/.vimrc ~/.vim
+ vcsh vim commit -m 'Initial commit of my Vim configuration'
+ # optionally push your files to a remote
+ vcsh vim remote add origin REMOTE
+ vcsh vim push origin master:master
-* Pull requests or issues on https://github.com/RichiH/vcsh
+If all that looks a _lot_ like standard `git`, that's no coincidence; it's
+a design feature.
-# 2 Introduction #
+Once you get familiar with `vcsh`, it's strongly suggested that you look
+into more advanced usage scenarios, especially on how to manage your
+`vcsh` and other repositories with [mr][mr].
-vcsh allows you to have several git repositories, all maintaining their working
-trees in $HOME without clobbering each other. That, in turn, means you can have
-one repository per config set (zsh, vim, ssh, etc), picking and choosing which
-configs you want to use on which machine.
-vcsh was designed with [mr] [1] in mind so you might want to install that, as
+# Introduction #
+
+[vcsh][vcsh] allows you to maintain several git repositories in one single
+directory. They all maintain their working trees without clobbering each other
+or interfering otherwise. By default, all git repositories maintained via
+`vcsh` are stored in `$HOME` but you can override this setting if you want to.
+All this means that you can have one repository per application or application
+family, i.e. `zsh`, `vim`, `ssh`, etc. This, in turn, allows you to clone
+custom sets of configurations onto different machines or even for different
+users; picking and mixing which configurations you want to use where.
+For example, you may not need to have your `mplayer` configuration on a server
+or available to root and you may want to maintain different configuration for
+`ssh` on your personal and your work machines.
+
+`vcsh` was designed with [mr][mr] in mind so you might want to install that, as
well.
-Read INSTALL.md for detailed setup instructions.
+Read `INSTALL.md` and `PACKAGING.md` for instructions specific to your operating
+system.
+
+
+## Talks ##
+
+Some people found it useful to look at slides and videos explaining how `vcsh`
+works instead of working through the docs, first.
+They can all be found [on the author's talk page][talks].
-The following overview will try to give you an idea of the use cases and
-advantages of vcsh. See sections 3 and 4 for detailed instructions and
-examples.
-# 3 Overview
+# Overview
-## 3.1 Comparison to Other Solutions ##
+## Comparison to Other Solutions ##
Most people who decide to put their dotfiles under version control start with a
-**single repository in $HOME**, adding all their dotfiles (and possibly more)
+single repository in `$HOME`, adding all their dotfiles (and possibly more)
to it. This works, of course, but can become a nuisance as soon as you try to
manage more than one host.
The next logical step is to create single-purpose repositories in, for example,
-~/.dotfiles and to create **symbolic links in $HOME**. This gives you the
+`~/.dotfiles` and to create symbolic links into `$HOME`. This gives you the
flexibility to check out only certain repositories on different hosts. The
downsides of this approach are the necessary manual steps of cloning and
-symlinking the individual repositories. It will probably become a nuisance when
-you try to manage more than two hosts.
+symlinking the individual repositories.
-**vcsh** takes this second approach one step further. It expects
-**single-purpose repositories** and stores them in a hidden directory (similar
-to ~/.dotfiles). However, it does not create symbolic links in $HOME; it puts
-the **actual files right into $HOME**.
+`vcsh` takes this second approach one step further. It expects
+single-purpose repositories and stores them in a hidden directory (similar
+to `~/.dotfiles`). However, it does not create symbolic links in `$HOME`; it
+puts the actual files right into `$HOME`.
-Furthermore, by making use of [mr] [1], it makes it very easy to enable/disable
-and clone a large number of repositories. The use of mr is technically optional
-(see 4.3), but it will be an integral part of the proposed system that follows.
+Furthermore, by making use of [mr][mr], it makes it very easy to enable/disable
+and clone a large number of repositories. The use of `mr` is technically
+optional (see section 4.3), but it will be an integral part of the proposed
+system that follows.
-## 3.2 Default Directory Layout ##
+## Default Directory Layout ##
To illustrate, this is what a possible directory structure looks like.
[DEFAULT]
jobs = 5
+ # Use if your mr does not have vcsh support in mainline, yet
+ include = cat /usr/share/mr/vcsh
include = cat ${XDG_CONFIG_HOME:-$HOME/.config}/mr/config.d/*
### repo.d ###
Optionally, merge your local and your global configs afterwards and push with
`vcsh run foo git push`.
-## 3.3 Moving into a New Host ##
+## Moving into a New Host ##
To illustrate further, the following steps could move your desired
configuration to a new host.
If you want to give vcsh a try, follow the instructions below.
-# 4 Getting Started #
+
+# Getting Started #
Below, you will find a few different methods for setting up vcsh:
2. The Steal-from-Template Way
3. The Manual Way
-### 4.1 The Template Way ###
+### The Template Way ###
-#### 4.1.1 Prerequisites ####
+#### Prerequisites ####
Make sure none of the following files and directories exist for your test
(user). If they do, move them away for now:
apt-get install mr
-#### 4.1.2 Clone the Template ####
+#### Install vcsh ####
+
+#### Debian ####
+
+If you are using Debian Squeeze, you will need to enable backports
+
+ apt-get install vcsh
+
+#### Arch Linux ####
+
+vcsh is availabe via [AUR](https://aur.archlinux.org/packages.php?ID=54164)
+and further documentation about the use of AUR is available
+[on Arch's wiki](https://wiki.archlinux.org/index.php/Arch_User_Repository).
+
+ cd /var/abs/local/
+ wget https://aur.archlinux.org/packages/vc/vcsh-git/vcsh-git.tar.gz
+ tar xfz vcsh-git.tar.gz
+ cd vcsh-git
+ makepkg -s
+ pacman -U vcsh*.pkg.tar.xz
+
+#### From source ####
+If your version of mr is older than version 1.07, make sure to put
+
+ include = cat /usr/share/mr/vcsh
+
+into your .mrconfig .
+
+ # choose a location for your checkout
cd $HOME
mkdir -p ~/work/git
- git clone git://github.com/RichiH/vcsh.git vcsh
- # make sure 'include = cat /usr/share/mr/vcsh' points to an exiting file
- vim .mrconfig
+ git clone git://github.com/RichiH/vcsh.git
cd vcsh
ln -s vcsh /usr/local/bin # or add it to your PATH
cd
+
+#### Clone the Template ####
+
vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr
-#### 4.1.3 Enable Your Test Repository ####
+#### Enable Your Test Repository ####
mv ~/.zsh ~/zsh.bak
mv ~/.zshrc ~/zshrc.bak
cd
mr up
-#### 4.1.4 Set Up Your Own Repositories ####
+#### Set Up Your Own Repositories ####
Now, it's time to edit the template config and fill it with your own remotes:
Done!
-### 4.2 The Steal-from-Template Way ###
+### The Steal-from-Template Way ###
You're welcome to clone the example repository:
poke me, RichiH, on Freenode (query) or OFTC (#vcs-home).
-### 4.3 The Manual Way ###
+### The Manual Way ###
This is how my old setup procedure looked like. Adapt it to your own style or
copy mine verbatim, either is fine.
~ % cd
~ % mr -j 5 up
-# 5 Usage #
-### 5.1 Keeping repositories Up-to-Date ###
+# Usage #
+
+### Keeping repositories Up-to-Date ###
This is the beauty of it all. Once you are set up, just run:
Neat.
-### 5.1 Making Changes ###
+### Making Changes ###
After you have made some changes, for which you would normally use `git add`
and `git commit`, use the vcsh wrapper (like above):
will be ignored by default. This is to show you only useful output when running
git-status. A fix for this problem is being worked on.
-### 5.3 Using vcsh without mr ###
+### Using vcsh without mr ###
vcsh encourages you to use [mr] [1]. It helps you manage a large number of
repositories by running the necessary vcsh commands for you. You may choose not
vcsh run $repo git pull;
done
-----------
-mr can be found at: [http://kitenet.net/~joey/code/mr/][1]
+# Contact #
+
+There are several ways to get in touch with the author and a small but committed
+community around the general idea of version controlling your (digital) life.
+
+* IRC: #vcs-home on irc.oftc.net
+
+* Mailing list: [http://lists.madduck.net/listinfo/vcs-home][vcs-home-list]
+
+* Pull requests or issues on [https://github.com/RichiH/vcsh][vcsh]
+
-[1]: http://kitenet.net/~joey/code/mr/ (http://kitenet.net/~joey/code/mr/)
+[mr]: http://kitenet.net/~joey/code/mr/
+[talks]: http://richardhartmann.de/talks/
+[vcsh]: https://github.com/RichiH/vcsh
+[vcs-home-list]: http://lists.madduck.net/listinfo/vcs-home
projects / code / vcsh.git / blobdiff