====== git(1) - the stupid content tracker ======

http://www.kernel.org/pub/software/scm/git/docs/
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
http://www.kernel.org/pub/software/scm/git/docs/hooks.txt

===== Importing a CVS archive =====

  $ git cvsimport -v -d <cvsroot> -C <destination> <module>

===== Emulating the CVS Development Model =====
Emulating the CVS Development Model

Start with an ordinary git working directory containing the project, and remove the checked-out files, keeping just the bare .git directory:
  $ mv project/.git /pub/repo.git
  $ rm -r project/
Next, give every team member read/write access to this repository. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted. If you don't want to give them a full shell on the machine, there is a restricted shell which only allows users to do git pushes and pulls; see git-shell(1).

Put all the committers in the same group, and make the repository writable by that group:
  $ chgrp -R $group repo.git
  $ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
  $ GIT_DIR=repo.git git repo-config core.sharedrepository true
Make sure committers have a umask of at most 027, so that the directories they create are writable and searchable by other group members.

Suppose this repository is now set up in /pub/repo.git on the host foo.com. Then as an individual committer you can clone the shared repository:
  $ git clone foo.com:/pub/repo.git/ my-project
  $ cd my-project
and hack away. The equivalent of cvs update is
  $ git pull origin
which merges in any work that others might have done since the clone operation.


===== handy commandlines =====

  $ git push origin master
  $ git push origin ## (update all remote-branches with same name as local branches)
  $ git push repo.shared.xz:/pub/scm/project.git/