| blob | 6b5c574fb5b08d4aa9c2136cd353435777707bc0 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 gitcvs-migration(7) Manual Page
407 </h1>
410 <p>gitcvs-migration -
411 git for CVS users
412 </p>
413 </div>
414 </div>
420 </div></div>
421 </div>
424 <div class="paragraph"><p>Git differs from CVS in that every working tree contains a repository with
425 a full copy of the project history, and no repository is inherently more
426 important than any other. However, you can emulate the CVS model by
427 designating a single shared repository which people can synchronize with;
428 this document explains how to do that.</p></div>
432 </div>
436 foo.com. Then as an individual committer you can clone the shared
437 repository over ssh with:</p></div>
440 <pre><tt>$ git clone foo.com:/pub/repo.git/ my-project
441 $ cd my-project</tt></pre>
442 </div></div>
447 </div></div>
449 operation. If there are uncommitted changes in your working tree, commit
450 them first before running git pull.</p></div>
452 <table><tr>
455 </td>
457 <div class="paragraph"><p>The <em>pull</em> command knows where to get updates from because of certain
460 page for details.</p></div>
461 </td>
462 </tr></table>
463 </div>
464 <div class="paragraph"><p>You can update the shared repository with your changes by first committing
469 </div></div>
472 complain, in which case you must pull any changes before attempting the
473 push again.</p></div>
474 <div class="paragraph"><p>In the <em>git push</em> command above we specify the name of the remote branch
476 any branches in the remote repository that have the same name as a branch
480 <pre><tt>$ git push origin
481 $ git push foo.com:/pub/project.git/</tt></pre>
482 </div></div>
485 </div>
489 possibly created from scratch or from a tarball (see
491 repository (see the next section).</p></div>
492 <div class="paragraph"><p>Assume your existing repo is at /home/alice/myproject. Create a new "bare"
493 repository (a repository without a working tree) and fetch your project into
494 it:</p></div>
497 <pre><tt>$ mkdir /pub/my-repo.git
498 $ cd /pub/my-repo.git
499 $ git --bare init --shared
500 $ git --bare fetch /home/alice/myproject master:master</tt></pre>
501 </div></div>
502 <div class="paragraph"><p>Next, give every team member read/write access to this repository. One
503 easy way to do this is to give all the team members ssh access to the
504 machine where the repository is hosted. If you don’t want to give them a
505 full shell on the machine, there is a restricted shell which only allows
508 writable by that group:</p></div>
512 </div></div>
513 <div class="paragraph"><p>Make sure committers have a umask of at most 027, so that the directories
514 they create are writable and searchable by other group members.</p></div>
515 </div>
520 sure it is in your path. Then cd to a checked out CVS working directory
521 of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p></div>
525 </div></div>
528 <div class="paragraph"><p>The import checks out from CVS every revision of every file. Reportedly
529 cvsimport can average some twenty revisions per second, so for a
530 medium-sized project this should not take more than a couple of minutes.
531 Larger projects or remote repositories may take longer.</p></div>
532 <div class="paragraph"><p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
533 CVS branches are stored in git branches with the same names. The most
535 branch, so you can start adding your own changes right away.</p></div>
537 fetch any CVS updates that have been made in the meantime. For this to
538 work, you must not modify the imported branches; instead, create new
539 branches for your own changes, and merge in the imported branches as
540 necessary.</p></div>
542 of the imported directory, as described above. Then treat the imported
543 directory as another development clone for purposes of merging
544 incremental imports.</p></div>
545 </div>
549 points. You can use these, for example, to send all commits to the shared
554 </div>
555 <h2 id="_providing_cvs_access_to_a_git_repository">Providing CVS Access to a git Repository</h2>
557 <div class="paragraph"><p>It is also possible to provide true CVS access to a git repository, so
559 details.</p></div>
560 </div>
563 <div class="paragraph"><p>CVS users are accustomed to giving a group of developers commit access to
564 a common repository. As we’ve seen, this is also possible with git.
565 However, the distributed nature of git allows other development models,
566 and you may want to first consider whether one of them might be a better
567 fit for your project.</p></div>
568 <div class="paragraph"><p>For example, you can choose a single person to maintain the project’s
569 primary public repository. Other developers then clone this repository
570 and each work in their own clone. When they have a series of changes that
571 they’re happy with, they ask the maintainer to pull from the branch
572 containing the changes. The maintainer reviews their changes and pulls
573 them into the primary repository, which other developers pull from as
574 necessary to stay coordinated. The Linux kernel and other projects use
575 variants of this model.</p></div>
576 <div class="paragraph"><p>With a small group, developers may just pull changes from each other’s
577 repositories without the need for a central maintainer.</p></div>
578 </div>
587 </div>
591 </div>
595 </div>
596 </div>
597 </body>
598 </html>