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 First, install version 2.1 or higher of cvsps from
103 http://www.cobite.com/cvsps/ and make sure it is in your path. Then cd
104 to a checked out CVS working directory of the project you are
105 interested in and run git-cvsimport(1):
106 $ git cvsimport -C <destination> <module>
108 This puts a Git archive of the named CVS module in the directory
111 <destination>, which will be created if necessary.
112 The import checks out from CVS every revision of every file. Reportedly
114 cvsimport can average some twenty revisions per second, so for a
115 medium-sized project this should not take more than a couple of
116 minutes. Larger projects or remote repositories may take longer.
117 The main trunk is stored in the Git branch named origin, and additional
119 CVS branches are stored in Git branches with the same names. The most
120 recent version of the main trunk is also left checked out on the master
121 branch, so you can start adding your own changes right away.
122 The import is incremental, so if you call it again next month it will
124 fetch any CVS updates that have been made in the meantime. For this to
125 work, you must not modify the imported branches; instead, create new
126 branches for your own changes, and merge in the imported branches as
127 necessary.
128 If you want a shared repository, you will need to make a bare clone of
130 the imported directory, as described above. Then treat the imported
131 directory as another development clone for purposes of merging
132 incremental imports.
133
135 Git allows you to specify scripts called "hooks" to be run at certain
136 points. You can use these, for example, to send all commits to the
137 shared repository to a mailing list. See githooks(5).
138 You can enforce finer grained permissions using update hooks. See
140 Controlling access to branches using update hooks[1].
141
143 It is also possible to provide true CVS access to a Git repository, so
144 that developers can still use CVS; see git-cvsserver(1) for details.
145
147 CVS users are accustomed to giving a group of developers commit access
148 to a common repository. As we’ve seen, this is also possible with Git.
149 However, the distributed nature of Git allows other development models,
150 and you may want to first consider whether one of them might be a
151 better fit for your project.
152 For example, you can choose a single person to maintain the project’s
154 primary public repository. Other developers then clone this repository
155 and each work in their own clone. When they have a series of changes
156 that they’re happy with, they ask the maintainer to pull from the
157 branch containing the changes. The maintainer reviews their changes and
158 pulls them into the primary repository, which other developers pull
159 from as necessary to stay coordinated. The Linux kernel and other
160 projects use variants of this model.
161 With a small group, developers may just pull changes from each other’s
163 repositories without the need for a central maintainer.
164
166 gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7),
167 Everyday Git[2], The Git User’s Manual[3]
168
170 Part of the git(1) suite.
171
173 1. Controlling access to branches using update hooks
174 file:///usr/share/doc/git-1.8.3.1/howto/update-hook-example.txt
175 2. Everyday Git
177 file:///usr/share/doc/git-1.8.3.1/everyday.html
178 3. The Git User’s Manual
180 file:///usr/share/doc/git-1.8.3.1/user-manual.html
181Git 1.8.3.1 11/19/2018 GITCVS-MIGRATION(7)