| blob | 15f601070d2eac861eec800efc39ea29769f64b3 |
4 <head>
8 /* Debug borders */
10 /*
11 border: 1px solid red;
12 */
13 }
15 body {
17 }
19 a {
22 }
25 }
27 em {
29 }
31 strong {
33 }
35 tt {
37 }
45 }
49 }
50 h2 {
52 }
53 h3 {
55 }
56 h3 + * {
58 }
63 }
65 hr {
67 }
69 p {
72 }
74 pre {
77 }
79 span#author {
84 }
85 span#email {
86 }
87 span#revision {
89 }
91 div#footer {
97 }
98 div#footer-text {
101 }
102 div#footer-badges {
105 }
107 div#preamble,
114 }
118 }
122 }
124 /* Block element titles. */
131 }
134 }
138 }
141 }
144 }
150 }
154 }
159 }
163 }
167 }
170 }
179 }
183 }
188 }
192 }
198 dl {
201 }
202 dt {
206 }
209 }
213 }
216 }
220 }
221 thead {
224 }
225 tfoot {
227 }
232 }
235 }
240 }
243 }
247 }
249 div#toctitle {
256 }
261 }
265 }
269 }
273 }
275 /* Workarounds for IE6's broken and incomplete CSS2. */
281 }
287 }
293 }
297 }
302 }
304 /* IE6 sets dynamically generated links as visited. */
306 </style>
308 </head>
309 <body>
311 <h1>
312 gitcvs-migration(7) Manual Page
313 </h1>
316 <p>gitcvs-migration -
317 git for CVS users
318 </p>
319 </div>
320 </div>
324 </div>
328 a full copy of the project history, and no repository is inherently more
329 important than any other. However, you can emulate the CVS model by
330 designating a single shared repository which people can synchronize with;
331 this document explains how to do that.</p></div>
335 </div>
339 foo.com. Then as an individual committer you can clone the shared
340 repository over ssh with:</p></div>
343 <pre><tt>$ git clone foo.com:/pub/repo.git/ my-project
344 $ cd my-project</tt></pre>
345 </div></div>
350 </div></div>
352 operation. If there are uncommitted changes in your working tree, commit
353 them first before running git pull.</p></div>
355 <table><tr>
358 </td>
360 <div class="para"><p>The <em>pull</em> command knows where to get updates from because of certain
363 page for details.</p></div>
364 </td>
365 </tr></table>
366 </div>
372 </div></div>
375 complain, in which case you must pull any changes before attempting the
376 push again.</p></div>
377 <div class="para"><p>In the <em>git push</em> command above we specify the name of the remote branch
379 any branches in the remote repository that have the same name as a branch
383 <pre><tt>$ git push origin
384 $ git push foo.com:/pub/project.git/</tt></pre>
385 </div></div>
388 </div>
392 possibly created from scratch or from a tarball (see
394 repository (see the next section).</p></div>
396 repository (a repository without a working tree) and fetch your project into
397 it:</p></div>
400 <pre><tt>$ mkdir /pub/my-repo.git
401 $ cd /pub/my-repo.git
402 $ git --bare init --shared
403 $ git --bare fetch /home/alice/myproject master:master</tt></pre>
404 </div></div>
406 easy way to do this is to give all the team members ssh access to the
407 machine where the repository is hosted. If you don't want to give them a
408 full shell on the machine, there is a restricted shell which only allows
411 writable by that group:</p></div>
415 </div></div>
417 they create are writable and searchable by other group members.</p></div>
418 </div>
423 sure it is in your path. Then cd to a checked out CVS working directory
424 of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p></div>
428 </div></div>
432 cvsimport can average some twenty revisions per second, so for a
433 medium-sized project this should not take more than a couple of minutes.
434 Larger projects or remote repositories may take longer.</p></div>
435 <div class="para"><p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
436 CVS branches are stored in git branches with the same names. The most
438 branch, so you can start adding your own changes right away.</p></div>
440 fetch any CVS updates that have been made in the meantime. For this to
441 work, you must not modify the imported branches; instead, create new
442 branches for your own changes, and merge in the imported branches as
443 necessary.</p></div>
445 of the imported directory, as described above. Then treat the imported
446 directory as another development clone for purposes of merging
447 incremental imports.</p></div>
448 </div>
452 points. You can use these, for example, to send all commits to the shared
457 </div>
458 <h2 id="_providing_cvs_access_to_a_git_repository">Providing CVS Access to a git Repository</h2>
462 details.</p></div>
463 </div>
467 a common repository. As we've seen, this is also possible with git.
468 However, the distributed nature of git allows other development models,
469 and you may want to first consider whether one of them might be a better
470 fit for your project.</p></div>
472 primary public repository. Other developers then clone this repository
473 and each work in their own clone. When they have a series of changes that
474 they're happy with, they ask the maintainer to pull from the branch
475 containing the changes. The maintainer reviews their changes and pulls
476 them into the primary repository, which other developers pull from as
477 necessary to stay coordinated. The Linux kernel and other projects use
478 variants of this model.</p></div>
480 repositories without the need for a central maintainer.</p></div>
481 </div>
490 </div>
494 </div>
498 </div>
499 </div>
500 </body>
501 </html>