]>
Commit | Line | Data |
---|---|---|
72e9340c | 1 | git for CVS users |
fcbfd5a6 LT |
2 | ================= |
3 | ||
cd976f5c BF |
4 | Git differs from CVS in that every working tree contains a repository with |
5 | a full copy of the project history, and no repository is inherently more | |
6 | important than any other. However, you can emulate the CVS model by | |
7 | designating a single shared repository which people can synchronize with; | |
8 | this document explains how to do that. | |
fcbfd5a6 | 9 | |
b8bc67ce BF |
10 | Some basic familiarity with git is required. This |
11 | link:tutorial.html[tutorial introduction to git] should be sufficient. | |
fcbfd5a6 | 12 | |
cd976f5c BF |
13 | Developing against a shared repository |
14 | -------------------------------------- | |
fcbfd5a6 | 15 | |
cd976f5c | 16 | Suppose a shared repository is set up in /pub/repo.git on the host |
37425065 | 17 | foo.com. Then as an individual committer you can clone the shared |
cd976f5c | 18 | repository over ssh with: |
b8bc67ce BF |
19 | |
20 | ------------------------------------------------ | |
21 | $ git clone foo.com:/pub/repo.git/ my-project | |
22 | $ cd my-project | |
23 | ------------------------------------------------ | |
24 | ||
25 | and hack away. The equivalent of `cvs update` is | |
26 | ||
27 | ------------------------------------------------ | |
28 | $ git pull origin | |
29 | ------------------------------------------------ | |
30 | ||
31 | which merges in any work that others might have done since the clone | |
cd976f5c BF |
32 | operation. If there are uncommitted changes in your working tree, commit |
33 | them first before running git pull. | |
b8bc67ce BF |
34 | |
35 | [NOTE] | |
36 | ================================ | |
c04197ee BF |
37 | The `pull` command knows where to get updates from because of certain |
38 | configuration variables that were set by the first `git clone` | |
e0d10e1c | 39 | command; see `git config -l` and the gitlink:git-config[1] man |
c04197ee | 40 | page for details. |
b8bc67ce BF |
41 | ================================ |
42 | ||
4cfeccc7 BF |
43 | You can update the shared repository with your changes by first committing |
44 | your changes, and then using the gitlink:git-push[1] command: | |
fcbfd5a6 | 45 | |
b8bc67ce BF |
46 | ------------------------------------------------ |
47 | $ git push origin master | |
48 | ------------------------------------------------ | |
fcbfd5a6 | 49 | |
4003a58e BF |
50 | to "push" those commits to the shared repository. If someone else has |
51 | updated the repository more recently, `git push`, like `cvs commit`, will | |
52 | complain, in which case you must pull any changes before attempting the | |
53 | push again. | |
7da71deb | 54 | |
b8bc67ce BF |
55 | In the `git push` command above we specify the name of the remote branch |
56 | to update (`master`). If we leave that out, `git push` tries to update | |
57 | any branches in the remote repository that have the same name as a branch | |
58 | in the local repository. So the last `push` can be done with either of: | |
7da71deb | 59 | |
b8bc67ce BF |
60 | ------------ |
61 | $ git push origin | |
cd976f5c | 62 | $ git push foo.com:/pub/project.git/ |
b8bc67ce | 63 | ------------ |
7da71deb | 64 | |
b8bc67ce BF |
65 | as long as the shared repository does not have any branches |
66 | other than `master`. | |
67 | ||
cd976f5c BF |
68 | Setting Up a Shared Repository |
69 | ------------------------------ | |
70 | ||
71 | We assume you have already created a git repository for your project, | |
72 | possibly created from scratch or from a tarball (see the | |
73 | link:tutorial.html[tutorial]), or imported from an already existing CVS | |
74 | repository (see the next section). | |
75 | ||
4cfeccc7 BF |
76 | Assume your existing repo is at /home/alice/myproject. Create a new "bare" |
77 | repository (a repository without a working tree) and fetch your project into | |
78 | it: | |
cd976f5c BF |
79 | |
80 | ------------------------------------------------ | |
4cfeccc7 BF |
81 | $ mkdir /pub/my-repo.git |
82 | $ cd /pub/my-repo.git | |
5c94f87e | 83 | $ git --bare init --shared |
4cfeccc7 | 84 | $ git --bare fetch /home/alice/myproject master:master |
cd976f5c BF |
85 | ------------------------------------------------ |
86 | ||
87 | Next, give every team member read/write access to this repository. One | |
88 | easy way to do this is to give all the team members ssh access to the | |
89 | machine where the repository is hosted. If you don't want to give them a | |
90 | full shell on the machine, there is a restricted shell which only allows | |
91 | users to do git pushes and pulls; see gitlink:git-shell[1]. | |
92 | ||
93 | Put all the committers in the same group, and make the repository | |
94 | writable by that group: | |
95 | ||
96 | ------------------------------------------------ | |
4cfeccc7 | 97 | $ chgrp -R $group /pub/my-repo.git |
cd976f5c BF |
98 | ------------------------------------------------ |
99 | ||
100 | Make sure committers have a umask of at most 027, so that the directories | |
101 | they create are writable and searchable by other group members. | |
102 | ||
103 | Importing a CVS archive | |
104 | ----------------------- | |
105 | ||
106 | First, install version 2.1 or higher of cvsps from | |
107 | link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make | |
4cfeccc7 BF |
108 | sure it is in your path. Then cd to a checked out CVS working directory |
109 | of the project you are interested in and run gitlink:git-cvsimport[1]: | |
cd976f5c BF |
110 | |
111 | ------------------------------------------- | |
4cfeccc7 | 112 | $ git cvsimport -C <destination> |
cd976f5c BF |
113 | ------------------------------------------- |
114 | ||
115 | This puts a git archive of the named CVS module in the directory | |
4cfeccc7 | 116 | <destination>, which will be created if necessary. |
cd976f5c BF |
117 | |
118 | 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 minutes. | |
121 | Larger projects or remote repositories may take longer. | |
122 | ||
123 | 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 | ||
128 | 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. | |
b8bc67ce BF |
133 | |
134 | Advanced Shared Repository Management | |
135 | ------------------------------------- | |
136 | ||
137 | Git allows you to specify scripts called "hooks" to be run at certain | |
138 | points. You can use these, for example, to send all commits to the shared | |
b85c4bbb | 139 | repository to a mailing list. See link:hooks.html[Hooks used by git]. |
b8bc67ce BF |
140 | |
141 | You can enforce finer grained permissions using update hooks. See | |
142 | link:howto/update-hook-example.txt[Controlling access to branches using | |
143 | update hooks]. | |
fcbfd5a6 | 144 | |
cd976f5c BF |
145 | Providing CVS Access to a git Repository |
146 | ---------------------------------------- | |
147 | ||
148 | It is also possible to provide true CVS access to a git repository, so | |
149 | that developers can still use CVS; see gitlink:git-cvsserver[1] for | |
150 | details. | |
151 | ||
152 | Alternative Development Models | |
153 | ------------------------------ | |
154 | ||
155 | CVS users are accustomed to giving a group of developers commit access to | |
156 | a common repository. As we've seen, this is also possible with git. | |
157 | However, the distributed nature of git allows other development models, | |
158 | and you may want to first consider whether one of them might be a better | |
159 | fit for your project. | |
160 | ||
161 | For example, you can choose a single person to maintain the project's | |
162 | primary public repository. Other developers then clone this repository | |
163 | and each work in their own clone. When they have a series of changes that | |
164 | they're happy with, they ask the maintainer to pull from the branch | |
165 | containing the changes. The maintainer reviews their changes and pulls | |
166 | them into the primary repository, which other developers pull from as | |
167 | necessary to stay coordinated. The Linux kernel and other projects use | |
168 | variants of this model. | |
b0bf8f24 | 169 | |
cd976f5c BF |
170 | With a small group, developers may just pull changes from each other's |
171 | repositories without the need for a central maintainer. |