about summary refs log tree commit diff
path: root/third_party/git/Documentation/gitcvs-migration.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/gitcvs-migration.txt')
-rw-r--r--third_party/git/Documentation/gitcvs-migration.txt206
1 files changed, 0 insertions, 206 deletions
diff --git a/third_party/git/Documentation/gitcvs-migration.txt b/third_party/git/Documentation/gitcvs-migration.txt
deleted file mode 100644
index 1cd1283d0f81..000000000000
--- a/third_party/git/Documentation/gitcvs-migration.txt
+++ /dev/null
@@ -1,206 +0,0 @@
-gitcvs-migration(7)
-===================
-
-NAME
-----
-gitcvs-migration - Git for CVS users
-
-SYNOPSIS
---------
-[verse]
-'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
-linkgit:gittutorial[7] and
-linkgit: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 linkgit:git-config[1] man
-page for details.
-================================
-
-You can update the shared repository with your changes by first committing
-your changes, and then using the 'git push' command:
-
-------------------------------------------------
-$ git push origin master
-------------------------------------------------
-
-to "push" those commits to the shared repository.  If someone else has
-updated the repository more recently, 'git push', like 'cvs commit', will
-complain, in which case you must pull any changes before attempting the
-push again.
-
-In the 'git push' command above we specify the name of the remote branch
-to update (`master`).  If we leave that out, 'git push' tries to update
-any branches in the remote repository that have the same name as a branch
-in the local repository.  So the last 'push' can be done with either of:
-
-------------
-$ git push origin
-$ git push foo.com:/pub/project.git/
-------------
-
-as long as the shared repository does not have any branches
-other than `master`.
-
-Setting Up a Shared Repository
-------------------------------
-
-We assume you have already created a Git repository for your project,
-possibly created from scratch or from a tarball (see
-linkgit:gittutorial[7]), or imported from an already existing CVS
-repository (see the next section).
-
-Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
-repository (a repository without a working tree) and fetch your project into
-it:
-
-------------------------------------------------
-$ mkdir /pub/my-repo.git
-$ cd /pub/my-repo.git
-$ git --bare init --shared
-$ git --bare fetch /home/alice/myproject master:master
-------------------------------------------------
-
-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 linkgit:git-shell[1].
-
-Put all the committers in the same group, and make the repository
-writable by that group:
-
-------------------------------------------------
-$ chgrp -R $group /pub/my-repo.git
-------------------------------------------------
-
-Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.
-
-Importing a CVS archive
------------------------
-
-NOTE: These instructions use the `git-cvsimport` script which ships with
-git, but other importers may provide better results. See the note in
-linkgit:git-cvsimport[1] for other options.
-
-First, install version 2.1 or higher of cvsps from
-https://github.com/andreyvit/cvsps[https://github.com/andreyvit/cvsps] and make
-sure it is in your path.  Then cd to a checked out CVS working directory
-of the project you are interested in and run linkgit:git-cvsimport[1]:
-
--------------------------------------------
-$ git cvsimport -C <destination> <module>
--------------------------------------------
-
-This puts a Git archive of the named CVS module in the directory
-<destination>, which will be created if necessary.
-
-The import checks out from CVS every revision of every file.  Reportedly
-cvsimport can average some twenty revisions per second, so for a
-medium-sized project this should not take more than a couple of minutes.
-Larger projects or remote repositories may take longer.
-
-The main trunk is stored in the Git branch named `origin`, and additional
-CVS branches are stored in Git branches with the same names.  The most
-recent version of the main trunk is also left checked out on the `master`
-branch, so you can start adding your own changes right away.
-
-The import is incremental, so if you call it again next month it will
-fetch any CVS updates that have been made in the meantime.  For this to
-work, you must not modify the imported branches; instead, create new
-branches for your own changes, and merge in the imported branches as
-necessary.
-
-If you want a shared repository, you will need to make a bare clone
-of the imported directory, as described above. Then treat the imported
-directory as another development clone for purposes of merging
-incremental imports.
-
-Advanced Shared Repository Management
--------------------------------------
-
-Git allows you to specify scripts called "hooks" to be run at certain
-points.  You can use these, for example, to send all commits to the shared
-repository to a mailing list.  See linkgit:githooks[5].
-
-You can enforce finer grained permissions using update hooks.  See
-link:howto/update-hook-example.html[Controlling access to branches using
-update hooks].
-
-Providing CVS Access to a Git Repository
-----------------------------------------
-
-It is also possible to provide true CVS access to a Git repository, so
-that developers can still use CVS; see linkgit:git-cvsserver[1] for
-details.
-
-Alternative Development Models
-------------------------------
-
-CVS users are accustomed to giving a group of developers commit access to
-a common repository.  As we've seen, this is also possible with Git.
-However, the distributed nature of Git allows other development models,
-and you may want to first consider whether one of them might be a better
-fit for your project.
-
-For example, you can choose a single person to maintain the project's
-primary public repository.  Other developers then clone this repository
-and each work in their own clone.  When they have a series of changes that
-they're happy with, they ask the maintainer to pull from the branch
-containing the changes.  The maintainer reviews their changes and pulls
-them into the primary repository, which other developers pull from as
-necessary to stay coordinated.  The Linux kernel and other projects use
-variants of this model.
-
-With a small group, developers may just pull changes from each other's
-repositories without the need for a central maintainer.
-
-SEE ALSO
---------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
-linkgit:giteveryday[7],
-link:user-manual.html[The Git User's Manual]
-
-GIT
----
-Part of the linkgit:git[1] suite