1GITCVS-MIGRATION(7)               Git Manual               GITCVS-MIGRATION(7)
2
3
4

NAME

6       gitcvs-migration - Git for CVS users
7

SYNOPSIS

9       git cvsimport *
10

DESCRIPTION

12       Git differs from CVS in that every working tree contains a repository
13       with a full copy of the project history, and no repository is
14       inherently more important than any other. However, you can emulate the
15       CVS model by designating a single shared repository which people can
16       synchronize with; this document explains how to do that.
17
18       Some basic familiarity with Git is required. Having gone through
19       gittutorial(7) and gitglossary(7) should be sufficient.
20

DEVELOPING AGAINST A SHARED REPOSITORY

22       Suppose a shared repository is set up in /pub/repo.git on the host
23       foo.com. Then as an individual committer you can clone the shared
24       repository over ssh with:
25
26           $ git clone foo.com:/pub/repo.git/ my-project
27           $ cd my-project
28
29       and hack away. The equivalent of cvs update is
30
31           $ git pull origin
32
33       which merges in any work that others might have done since the clone
34       operation. If there are uncommitted changes in your working tree,
35       commit them first before running git pull.
36
37           Note
38           The pull command knows where to get updates from because of certain
39           configuration variables that were set by the first git clone
40           command; see git config -l and the git-config(1) man page for
41           details.
42
43       You can update the shared repository with your changes by first
44       committing your changes, and then using the git push command:
45
46           $ git push origin master
47
48       to "push" those commits to the shared repository. If someone else has
49       updated the repository more recently, git push, like cvs commit, will
50       complain, in which case you must pull any changes before attempting the
51       push again.
52
53       In the git push command above we specify the name of the remote branch
54       to update (master). If we leave that out, git push tries to update any
55       branches in the remote repository that have the same name as a branch
56       in the local repository. So the last push can be done with either of:
57
58           $ git push origin
59           $ git push foo.com:/pub/project.git/
60
61       as long as the shared repository does not have any branches other than
62       master.
63

SETTING UP A SHARED REPOSITORY

65       We assume you have already created a Git repository for your project,
66       possibly created from scratch or from a tarball (see gittutorial(7)),
67       or imported from an already existing CVS repository (see the next
68       section).
69
70       Assume your existing repo is at /home/alice/myproject. Create a new
71       "bare" repository (a repository without a working tree) and fetch your
72       project into it:
73
74           $ mkdir /pub/my-repo.git
75           $ cd /pub/my-repo.git
76           $ git --bare init --shared
77           $ git --bare fetch /home/alice/myproject master:master
78
79       Next, give every team member read/write access to this repository. One
80       easy way to do this is to give all the team members ssh access to the
81       machine where the repository is hosted. If you don’t want to give them
82       a full shell on the machine, there is a restricted shell which only
83       allows users to do Git pushes and pulls; see git-shell(1).
84
85       Put all the committers in the same group, and make the repository
86       writable by that group:
87
88           $ chgrp -R $group /pub/my-repo.git
89
90       Make sure committers have a umask of at most 027, so that the
91       directories they create are writable and searchable by other group
92       members.
93

IMPORTING A CVS ARCHIVE

95           Note
96           These instructions use the git-cvsimport script which ships with
97           git, but other importers may provide better results. See the note
98           in git-cvsimport(1) for other options.
99
100       First, install version 2.1 or higher of cvsps from
101       https://github.com/andreyvit/cvsps and make sure it is in your path.
102       Then cd to a checked out CVS working directory of the project you are
103       interested in and run git-cvsimport(1):
104
105           $ git cvsimport -C <destination> <module>
106
107       This puts a Git archive of the named CVS module in the directory
108       <destination>, which will be created if necessary.
109
110       The import checks out from CVS every revision of every file. Reportedly
111       cvsimport can average some twenty revisions per second, so for a
112       medium-sized project this should not take more than a couple of
113       minutes. Larger projects or remote repositories may take longer.
114
115       The main trunk is stored in the Git branch named origin, and additional
116       CVS branches are stored in Git branches with the same names. The most
117       recent version of the main trunk is also left checked out on the master
118       branch, so you can start adding your own changes right away.
119
120       The import is incremental, so if you call it again next month it will
121       fetch any CVS updates that have been made in the meantime. For this to
122       work, you must not modify the imported branches; instead, create new
123       branches for your own changes, and merge in the imported branches as
124       necessary.
125
126       If you want a shared repository, you will need to make a bare clone of
127       the imported directory, as described above. Then treat the imported
128       directory as another development clone for purposes of merging
129       incremental imports.
130

ADVANCED SHARED REPOSITORY MANAGEMENT

132       Git allows you to specify scripts called "hooks" to be run at certain
133       points. You can use these, for example, to send all commits to the
134       shared repository to a mailing list. See githooks(5).
135
136       You can enforce finer grained permissions using update hooks. See
137       Controlling access to branches using update hooks[1].
138

PROVIDING CVS ACCESS TO A GIT REPOSITORY

140       It is also possible to provide true CVS access to a Git repository, so
141       that developers can still use CVS; see git-cvsserver(1) for details.
142

ALTERNATIVE DEVELOPMENT MODELS

144       CVS users are accustomed to giving a group of developers commit access
145       to a common repository. As we’ve seen, this is also possible with Git.
146       However, the distributed nature of Git allows other development models,
147       and you may want to first consider whether one of them might be a
148       better fit for your project.
149
150       For example, you can choose a single person to maintain the project’s
151       primary public repository. Other developers then clone this repository
152       and each work in their own clone. When they have a series of changes
153       that they’re happy with, they ask the maintainer to pull from the
154       branch containing the changes. The maintainer reviews their changes and
155       pulls them into the primary repository, which other developers pull
156       from as necessary to stay coordinated. The Linux kernel and other
157       projects use variants of this model.
158
159       With a small group, developers may just pull changes from each other’s
160       repositories without the need for a central maintainer.
161

SEE ALSO

163       gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7),
164       giteveryday(7), The Git User’s Manual[2]
165

GIT

167       Part of the git(1) suite
168

NOTES

170        1. Controlling access to branches using update hooks
171           file:///usr/share/doc/git/howto/update-hook-example.html
172
173        2. The Git User’s Manual
174           file:///usr/share/doc/git/user-manual.html
175
176
177
178Git 2.39.1                        2023-01-13               GITCVS-MIGRATION(7)
Impressum