Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Administration
Server Admin
Plumbing Commands
- 1.7.6.2 → 1.7.12.3 no changes
-
1.7.6.1
08/24/11
- 1.7.0.1 → 1.7.6 no changes
-
1.7.0
02/12/10
- 1.6.3 → 1.6.6.3 no changes
-
1.6.2.5
05/03/09
- 1.6.0.1 → 1.6.2.4 no changes
-
1.6.0
08/17/08
- 1.5.6.4 → 1.5.6.6 no changes
-
1.5.6.3
07/13/08
gitcvs-migration(7) Manual Page
NAME
gitcvs-migration - git for CVS users
SYNOPSIS
git cvsimport *
DESCRIPTION
Git differs from CVS in that every working tree contains a repository with a full copy of the project history, and no repository is inherently more important than any other. However, you can emulate the CVS model by designating a single shared repository which people can synchronize with; this document explains how to do that.
Some basic familiarity with git is required. Having gone through gittutorial(7) and gitglossary(7) should be sufficient.
Developing against a shared repository
Suppose a shared repository is set up in /pub/repo.git on the host foo.com. Then as an individual committer you can clone the shared repository over ssh with:
$ 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. If there are uncommitted changes in your working tree, commit them first before running git pull.
Note |
================================ The pull command knows where to get updates from because of certain configuration variables that were set by the first git-clone command; see git config -l and the git-config(1) man |