1GITCVS-MIGRATION(7) Git Manual GITCVS-MIGRATION(7)
2
6 gitcvs-migration - Git for CVS users
7
9 git cvsimport *
10
13 Git differs from CVS in that every working tree contains a repository
14 with a full copy of the project history, and no repository is
15 inherently more important than any other. However, you can emulate the
16 CVS model by designating a single shared repository which people can
17 synchronize with; this document explains how to do that.
18 Some basic familiarity with Git is required. Having gone through
20 gittutorial(7) and gitglossary(7) should be sufficient.
21
23 Suppose a shared repository is set up in /pub/repo.git on the host
24 foo.com. Then as an individual committer you can clone the shared
25 repository over ssh with:
26 $ git clone foo.com:/pub/repo.git/ my-project
28 $ cd my-project
29 and hack away. The equivalent of cvs update is
32 $ git pull origin
34 which merges in any work that others might have done since the clone
37 operation. If there are uncommitted changes in your working tree,
38 commit them first before running git pull.
39 Note
41 The pull command knows where to get updates from because of certain
42 configuration variables that were set by the first git clone
43 command; see git config -l and the git-config(1) man page for
44 details.
45 You can update the shared repository with your changes by first
47 committing your changes, and then using the git push command:
48 $ git push origin master
50 to "push" those commits to the shared repository. If someone else has
53 updated the repository more recently, git push, like cvs commit, will
54 complain, in which case you must pull any changes before attempting the
55 push again.
56 In the git push command above we specify the name of the remote branch
58 to update (master). If we leave that out, git push tries to update any
59 branches in the remote repository that have the same name as a branch
60 in the local repository. So the last push can be done with either of:
61 $ git push origin
63 $ git push foo.com:/pub/project.git/
64 as long as the shared repository does not have any branches other than
67 master.
68
70 We assume you have already created a Git repository for your project,
71 possibly created from scratch or from a tarball (see gittutorial(7)),
72 or imported from an already existing CVS repository (see the next
73 section).
74 Assume your existing repo is at /home/alice/myproject. Create a new
76 "bare" repository (a repository without a working tree) and fetch your
77 project into it:
78 $ mkdir /pub/my-repo.git
80 $ cd /pub/my-repo.git
81 $ git --bare init --shared
82 $ git --bare fetch /home/alice/myproject master:master
83 Next, give every team member read/write access to this repository. One
86 easy way to do this is to give all the team members ssh access to the
87 machine where the repository is hosted. If you don’t want to give them
88 a full shell on the machine, there is a restricted shell which only
89 allows users to do Git pushes and pulls; see git-shell(1).
90 Put all the committers in the same group, and make the repository
92 writable by that group:
93 $ chgrp -R $group /pub/my-repo.git
95 Make sure committers have a umask of at most 027, so that the
98 directories they create are writable and searchable by other group
99 members.
100
102 Note
103 These instructions use the git-cvsimport script which ships with
104 git, but other importers may provide better results. See the note
105 in git-cvsimport(1) for other options.
106 First, install version 2.1 or higher of cvsps from
108 https://github.com/andreyvit/cvsps and make sure it is in your path.
109 Then cd to a checked out CVS working directory of the project you are
110 interested in and run git-cvsimport(1):
111 $ git cvsimport -C <destination> <module>
113 This puts a Git archive of the named CVS module in the directory
116 <destination>, which will be created if necessary.
117 The import checks out from CVS every revision of every file. Reportedly
119 cvsimport can average some twenty revisions per second, so for a
120 medium-sized project this should not take more than a couple of
121 minutes. Larger projects or remote repositories may take longer.
122 The main trunk is stored in the Git branch named origin, and additional
124 CVS branches are stored in Git branches with the same names. The most
125 recent version of the main trunk is also left checked out on the master
126 branch, so you can start adding your own changes right away.
127 The import is incremental, so if you call it again next month it will
129 fetch any CVS updates that have been made in the meantime. For this to
130 work, you must not modify the imported branches; instead, create new
131 branches for your own changes, and merge in the imported branches as
132 necessary.
133 If you want a shared repository, you will need to make a bare clone of
135 the imported directory, as described above. Then treat the imported
136 directory as another development clone for purposes of merging
137 incremental imports.
138
140 Git allows you to specify scripts called "hooks" to be run at certain
141 points. You can use these, for example, to send all commits to the
142 shared repository to a mailing list. See githooks(5).
143 You can enforce finer grained permissions using update hooks. See
145 Controlling access to branches using update hooks[1].
146
148 It is also possible to provide true CVS access to a Git repository, so
149 that developers can still use CVS; see git-cvsserver(1) for details.
150
152 CVS users are accustomed to giving a group of developers commit access
153 to a common repository. As we’ve seen, this is also possible with Git.
154 However, the distributed nature of Git allows other development models,
155 and you may want to first consider whether one of them might be a
156 better fit for your project.
157 For example, you can choose a single person to maintain the project’s
159 primary public repository. Other developers then clone this repository
160 and each work in their own clone. When they have a series of changes
161 that they’re happy with, they ask the maintainer to pull from the
162 branch containing the changes. The maintainer reviews their changes and
163 pulls them into the primary repository, which other developers pull
164 from as necessary to stay coordinated. The Linux kernel and other
165 projects use variants of this model.
166 With a small group, developers may just pull changes from each other’s
168 repositories without the need for a central maintainer.
169
171 gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7),
172 giteveryday(7), The Git User’s Manual[2]
173
175 Part of the git(1) suite
176
178 1. Controlling access to branches using update hooks
179 file:///usr/share/doc/git/howto/update-hook-example.html
180 2. The Git User’s Manual
182 file:///usr/share/doc/git/user-manual.html
183Git 2.20.1 12/15/2018 GITCVS-MIGRATION(7)