X-Git-Url: https://git.madduck.net/code/vcsh.git/blobdiff_plain/ef3bcec8199fc1f35f61825909b0eda0512ada6e..a5523eb298c3bab97002f3b53161cfd6c328044a:/README.md?ds=sidebyside diff --git a/README.md b/README.md index 0a9b172..a83325d 100644 --- a/README.md +++ b/README.md @@ -1,39 +1,110 @@ -vcsh - manage and sync config files via git +vcsh - Version Control System for $HOME - multiple Git repositories in $HOME -# 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. +# Index -vcsh was designed with mr [1] in mind so you might want to install that, as well. +1. [Introduction](#introduction) +2. [30 second howto](#30-second-howto) +3. [Overview](#overview) +4. [Getting Started](#getting-started) +5. [Usage Exmaples](#usage-examples) +6. [Contact](#contact) -Read INSTALL.md for detailed setup instructions. -Questions? RichiH@{Freenode,OFTC,IRCnet} +# Introduction -## Comparison to Other Solutions ## +[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. -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) to it. -This works, of course, but can become a nuisance as soon as you try to manage more than one host. +`vcsh` was designed with [mr][mr], a tool to manage Multiple Repositories, in +mind and the two integrate very nicely. `mr` has native support for `vcsh` +repositories and to `vcsh`, `mr` is just another configuration to track. +This make setting up any new machine a breeze. It takes literally less than +five minutes to go from standard installation to fully set up system -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 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. +A lot of modern UNIX-based systems offer pacakges for `vcsh`. In case yours +does not read `INSTALL.md` for install instructions or `PACKAGING.md` to create +a package, yourself. If you do end up packaging `vcsh` please let us know so we +can give you your own packaging branch in the upstream repository. -**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**. +## Talks -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, but it will be an integral part of the proposed system that follows. +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]. -## Default Directory Layout ## + +# 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 + vcsh vim push -u origin master + # from now on you can push additional commits like this + vcsh vim push + +If all that looks a _lot_ like standard `git`, that's no coincidence; it's +a design feature. + + +# Overview + +## From zero to vcsh + +You put a lot of effort into your configuration and want to both protect and +distribute this configuration. + +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) +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 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. + +`vcsh` takes this approach one step further. It enables single-purpose +repositories and stores them in a hidden directory. However, it does not create +symbolic links in `$HOME`; it puts the actual files right into `$HOME`. + +As `vcsh` allows you to put an arbitrary number of distinct repositories into +your `$HOME`, you will end up with a lot of repositories very quickly. + +To manage both `vcsh` and other repositories, we suggest using [mr](mr). `mr` +takes care of pulling in and pushing out new data for a variety of version +control systems. + + +The last logical step is to maintain all those new repositores with an automated +tool instead of tracking them by hand. +This is where `mr` comes in. While the use of `mr` is technically +optional, but it will be an integral part of the proposed system that follows. + +## Default Directory Layout To illustrate, this is what a possible directory structure looks like. $HOME - |-- .config + |-- $XDG_CONFIG_HOME (defaults to $HOME/.config) | |-- mr | | |-- available.d | | | |-- zsh.vcsh @@ -46,11 +117,12 @@ To illustrate, this is what a possible directory structure looks like. | | | |-- vimperator.vcsh | | | `-- snippets.git | | `-- config.d - | | |-- zsh.mrconfig -> ../available.d/zsh.mrconfig - | | |-- gitconfigs.mrconfig -> ../available.d/gitconfigs.mrconfig - | | |-- tmux.mrconfig -> ../available.d/tmux.mrconfig - | | `-- vim.mrconfig -> ../available.d/vim.mrconfig + | | |-- zsh.vcsh -> ../available.d/zsh.vcsh + | | |-- gitconfigs.vcsh -> ../available.d/gitconfigs.vcsh + | | |-- tmux.vcsh -> ../available.d/tmux.vcsh + | | `-- vim.vcsh -> ../available.d/vim.vcsh | `-- vcsh + | |-- config | `-- repo.d | |-- zsh.git -----------+ | |-- gitconfigs.git | @@ -58,50 +130,332 @@ To illustrate, this is what a possible directory structure looks like. | `-- vim.git | |-- [...] | |-- .zshrc <----------------------+ - |-- .gitignore + |-- .gitignore.d + | `-- zsh |-- .mrconfig `-- .mrtrust -In this setup, ~/.mrconfig looks like: +### available.d - [DEFAULT] - jobs = 5 - include = cat ~/.config/mr/config.d/* +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 +with read-only access to my zshrc repo looks likes. I.e. in this specific +example, push can not work as you will be using the author's repository. This +is for demonstration, only. Of course, you are more than welcome to clone from +this repository and fork your own. + + [$XDG_CONFIG_HOME/vcsh/repo.d/zsh.git] + checkout = vcsh clone 'git://github.com/RichiH/zshrc.git' zsh + update = vcsh run zsh git pull + push = vcsh run zsh git push + status = vcsh run zsh git status + gc = vcsh run zsh git gc + +### config.d + +$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 +four repositories listed in config.d. -The files you see in ~/.config/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.mrconfig with read-only access to my zshrc repo looks likes. I.e. in this specific example, push can not work. +### ~/.mrconfig - [$HOME/.config/vcsh/repo.d/zsh.git] - checkout = vcsh clone 'git://github.com/RichiH/zshrc.git' - update = vcsh run bash git pull - push = vcsh run bash git push - status = vcsh run bash git status +Finally, ~/.mrconfig will tie together all those single files which will allow +you to conveniently run `mr up` etc. to manage all repositories. It looks like +this: -~/.config/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 four repositories listed in config.d. + [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/* -~/.config/vcsh/repo.d is the directory into which vcsh clones the git repositories. -Since their working trees are configured to be in $HOME, the files contained in those repositories will be put in $HOME directly (see .zshrc above). +### repo.d -vcsh will check if any file it would want to create exists. If it exists, vcsh 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`. +$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. +Of course, [mr] [mr] will work with this layout if configured according to this +document (see above). -## Moving into a New Host ## +vcsh will check if any file it would want to create exists. If it exists, vcsh +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`. -To illustrate further, the following steps could move your desired configuration to a new host. +## Moving into 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` -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. +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 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. 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 -1. making it easy to manage, clone and update a large number of repositories (thanks to mr) and +1. making it easy to manage, clone and update a large number of repositories + (thanks to mr) and 2. making it unnecessary to create symbolic links in $HOME (thanks to vcsh). ----------- +If you want to give vcsh a try, follow the instructions below. + + +# Getting Started + +Below, you will find a few different methods for setting up vcsh: + +1. The Template Way +2. The Steal-from-Template Way +3. The Manual Way + +### The Template Way + +#### 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/ + +All of the files are part of the template repository, the directory is where +the template will be stored. + + apt-get install mr + +#### 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 + 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 + +#### Enable Your Test Repository + + mv ~/.zsh ~/zsh.bak + mv ~/.zshrc ~/zshrc.bak + cd $XDG_CONFIG_HOME/mr/config.d/ + ln -s ../available.d/zsh.vcsh . # link, and thereby enable, the zsh repository + cd + mr up + +#### Set Up Your Own Repositories + +Now, it's time to edit the template config and fill it with your own remotes: + + vim $XDG_CONFIG_HOME/mr/available.d/mr.vcsh + vim $XDG_CONFIG_HOME/mr/available.d/zsh.vcsh + +And then create your own stuff: + + vcsh init foo + vcsh run foo git add -f bar baz quux + vcsh run foo git remote add origin git://quuux + vcsh run foo git commit + vcsh run foo git push + + cp $XDG_CONFIG_HOME/mr/available.d/mr.vcsh $XDG_CONFIG_HOME/mr/available.d/foo.vcsh + vim $XDG_CONFIG_HOME/mr/available.d/foo.vcsh # add your own repo + +Done! + +### The Steal-from-Template Way + +You're welcome to clone the example repository: + + 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). + + +### 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. + + # Create workspace + mkdir -p ~/work/git + cd !$ + + # Clone vcsh and make it available + git clone git://github.com/RichiH/vcsh.git vcsh + sudo ln -s ~/work/git/vcsh/vcsh /usr/bin/local + hash -r + +Grab my mr config. see below for details on how I set this up + + vcsh clone ssh:///mr.git + cd $XDG_CONFIG_HOME/mr/config.d/ + ln -s ../available.d/* . + + +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 + ~ % ls $XDG_CONFIG_HOME/mr/available.d # random selection of my repos + git-annex gitk.vcsh git.vcsh ikiwiki mr.vcsh reportbug.vcsh snippets.git wget.vcsh zsh.vcsh + ~ % + # then simply ln -s whatever you want on your local machine from + # $XDG_CONFIG_HOME/mr/available.d to $XDG_CONFIG_HOME/mr/config.d + ~ % cd + ~ % mr -j 5 up + + +# Usage Examples + +All examples in this section will use the short form of `vcsh` which is the +simplest way to interface with it. If you don't know what that means simply +ignore this fact for now and follow the examples. + +## Initialize a new repository "vim" + + vcsh init vim + +## Clone an existing repository + + vcsh clone + +## Add files to repository "vim" + + vcsh vim add ~/.vimrc ~/.vim + vcsh vim commit -m 'Update Vim configuration' + +## Add a remote for repository "vim" + + vcsh vim remote add origin + vcsh vim push origin master:master + vcsh vim branch --track master origin/master + +## Push to remote of repository "vim" + + vcsh vim push + +## Pull from remote of repository "vim" + + vcsh vim pull + + +# mr usage ; will be factored out & rewritten + +### Keeping repositories Up-to-Date + +This is the beauty of it all. Once you are set up, just run: + + mr up + mr push + +Neat. + +### 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): + + vcsh run foo git add -f bar baz quux + vcsh run foo git commit + vcsh run foo git push + +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. + +### Using vcsh without mr + +vcsh encourages you to use [mr][mr]. It helps you manage a large number of +repositories by running the necessary vcsh commands for you. You may choose not +to use mr, in which case you will have to run those commands manually or by +other means. + + +To initialize a new repository: `vcsh init zsh` + +To clone a repository: `vcsh clone ssh:///zsh.git` + +To interact with a repository, use the regular Git commands, but prepend them +with `vcsh run $repository_name`. For example: + + vcsh run zsh git status + vcsh run zsh git add -f .zshrc + vcsh run zsh git commit + +Obviously, without mr keeping repositories up-to-date, it will have to be done +manually. Alternatively, you could try something like this: + + for repo in `vcsh list`; do + vcsh run $repo git pull; + done + + +# 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/ +[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