X-Git-Url: https://git.madduck.net/code/vcsh.git/blobdiff_plain/29361a983d6723c582e5600feff39ceabc9c590d..b3e58bee42e266888583c0b0bbf4347fd6ac0ad2:/README.md?ds=sidebyside diff --git a/README.md b/README.md index bdc26bf..78dca61 100644 --- a/README.md +++ b/README.md @@ -1,66 +1,108 @@ -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. [Contact](#contact) +3. [Introduction](#introduction) +4. [Overview](#overview) +5. [Getting Started](#getting-started) +6. [Usage](#usage) + + +# 30 second howto # + +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: + + 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 + +If all that looks a _lot_ like standard `git`, that's no coincidence; it's +a design feature. + +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]. -# 1 Contact # + +# 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: vcs-home@lists.madduck.net +* Mailing list: [http://lists.madduck.net/listinfo/vcs-home][vcs-home-list] + +* Pull requests or issues on [https://github.com/RichiH/vcsh][vcsh] -* Pull requests or issues on https://github.com/RichiH/vcsh -# 2 Introduction # +# Introduction # -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][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 that 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] [1] in mind so you might want to install that, as +`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. 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 +advantages of `vcsh`. See sections 3 and 4 for detailed instructions and examples. -# 3 Overview +## Talks ## + +Some people found it useful to look at slides and videos explaining how `vcsh` +works. +They can all be found [on the author's talk page][talks]. + -## 3.1 Comparison to Other Solutions ## +# Overview + +## 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. @@ -98,7 +140,7 @@ To illustrate, this is what a possible directory structure looks like. ### available.d ### -The files you see in $XDG_CONFIG_HOME/mr/available.d are mr configuration files +The files you see in $XDG\_CONFIG\_HOME/mr/available.d are mr configuration files that contain the commands to manage (checkout, update etc.) a single repository. vcsh repo configs end in .vcsh, git configs end in .git, etc. This is optional and your preference. For example, this is what a zsh.vcsh @@ -116,7 +158,7 @@ this repository and fork your own. ### config.d ### -$XDG_CONFIG_HOME/mr/available.d contains *all available* repositories. Only +$XDG\_CONFIG\_HOME/mr/available.d contains *all available* repositories. Only files/links present in mr/config.d, however, will be used by mr. That means that in this example, only the zsh, gitconfigs, tmux and vim repositories will be checked out. A simple `mr update` run in $HOME will clone or update those @@ -130,11 +172,13 @@ this: [DEFAULT] jobs = 5 - include = cat $XDG_CONFIG_HOME/mr/config.d/* + # 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 ### -$XDG_CONFIG_HOME/vcsh/repo.d is the directory where all git repositories which +$XDG\_CONFIG\_HOME/vcsh/repo.d is the directory where all git repositories which are under vcsh's control are located. Since their working trees are configured to be in $HOME, the files contained in those repositories will be put in $HOME directly. @@ -146,17 +190,19 @@ will throw a warning and exit. Move away your old config and try again. 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. 1. Clone the mr repository (containing available.d, config.d etc.); for - example: `vcsh clone git://github.com/RichiH/vcsh_mr_template.git` + example: `vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr` 2. Choose your repositories by linking them in config.d (or go with the default you may have already configured by adding symlinks to git). -3. Run mr to clone the repositories: `cd; mr update`. -4. Done. +3. Make sure the line 'include = cat /usr/share/mr/vcsh' in .mrconfig points + to an existing file +4. Run mr to clone the repositories: `cd; mr update`. +5. Done. Hopefully the above could help explain how this approach saves time by @@ -166,7 +212,8 @@ Hopefully the above could help explain how this approach saves time by 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: @@ -174,36 +221,67 @@ 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: * ~/.gitignore.d * ~/.mrconfig -* $XDG_CONFIG_HOME/mr/available.d/mr.vcsh -* $XDG_CONFIG_HOME/mr/available.d/zsh.vcsh -* $XDG_CONFIG_HOME/mr/config.d/mr.vcsh -* $XDG_CONFIG_HOME/vcsh/repo.d/mr.git/ +* $XDG\_CONFIG\_HOME/mr/available.d/mr.vcsh +* $XDG\_CONFIG\_HOME/mr/available.d/zsh.vcsh +* $XDG\_CONFIG\_HOME/mr/config.d/mr.vcsh +* $XDG\_CONFIG\_HOME/vcsh/repo.d/mr.git/ All of the files are part of the template repository, the directory is where the template will be stored. 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 - cd !$ - git clone git://github.com/RichiH/vcsh.git vcsh + git clone git://github.com/RichiH/vcsh.git cd vcsh - ln -s vcsh /usr/local/bin # or add it to your PATH + ln -s vcsh /usr/local/bin # or add it to your PATH cd - vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr.vcsh -#### 4.1.3 Enable Your Test Repository #### +#### Clone the Template #### + + vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr + +#### Enable Your Test Repository #### mv ~/.zsh ~/zsh.bak mv ~/.zshrc ~/zshrc.bak @@ -212,7 +290,7 @@ the template will be stored. 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: @@ -232,17 +310,19 @@ And then create your own stuff: Done! -### 4.2 The Steal-from-Template Way ### +### The Steal-from-Template Way ### You're welcome to clone the example repository: - vcsh clone git://github.com/RichiH/vcsh_mr_template.git + vcsh clone git://github.com/RichiH/vcsh_mr_template.git mr + # make sure 'include = cat /usr/share/mr/vcsh' points to an exiting file + vim .mrconfig Look around in the clone. It should be reasonably simple to understand. If not, 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. @@ -267,6 +347,8 @@ mr is used to actually retrieve configs, etc ~ % cat ~/.mrconfig [DEFAULT] + # adapt /usr/share/mr/vcsh to your system if needed + include = cat /usr/share/mr/vcsh include = cat $XDG_CONFIG_HOME/mr/config.d/* ~ % echo $XDG_CONFIG_HOME /home/richih/.config @@ -278,9 +360,10 @@ mr is used to actually retrieve configs, etc ~ % 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: @@ -289,7 +372,7 @@ 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): @@ -302,7 +385,7 @@ By the way, you'll have to use -f/--force flag with git-add because all files 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 @@ -329,8 +412,8 @@ manually. Alternatively, you could try something like this: vcsh run $repo git pull; done ----------- - -mr can be found at: [http://kitenet.net/~joey/code/mr/][1] -[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