| blob | 3778aac05fa8642d1bf825855b035ef5929177cc |
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>
418 </div>
421 <div class="paragraph"><p>Git differs from CVS in that every working tree contains a repository with
422 a full copy of the project history, and no repository is inherently more
423 important than any other. However, you can emulate the CVS model by
424 designating a single shared repository which people can synchronize with;
425 this document explains how to do that.</p></div>
429 </div>
433 foo.com. Then as an individual committer you can clone the shared
434 repository over ssh with:</p></div>
437 <pre><tt>$ git clone foo.com:/pub/repo.git/ my-project
438 $ cd my-project</tt></pre>
439 </div></div>
444 </div></div>
446 operation. If there are uncommitted changes in your working tree, commit
447 them first before running git pull.</p></div>
449 <table><tr>
452 </td>
454 <div class="paragraph"><p>The <em>pull</em> command knows where to get updates from because of certain
457 page for details.</p></div>
458 </td>
459 </tr></table>
460 </div>
461 <div class="paragraph"><p>You can update the shared repository with your changes by first committing
466 </div></div>
469 complain, in which case you must pull any changes before attempting the
470 push again.</p></div>
471 <div class="paragraph"><p>In the <em>git push</em> command above we specify the name of the remote branch
473 any branches in the remote repository that have the same name as a branch
477 <pre><tt>$ git push origin
478 $ git push foo.com:/pub/project.git/</tt></pre>
479 </div></div>
482 </div>
486 possibly created from scratch or from a tarball (see
488 repository (see the next section).</p></div>
489 <div class="paragraph"><p>Assume your existing repo is at /home/alice/myproject. Create a new "bare"
490 repository (a repository without a working tree) and fetch your project into
491 it:</p></div>
494 <pre><tt>$ mkdir /pub/my-repo.git
495 $ cd /pub/my-repo.git
496 $ git --bare init --shared
497 $ git --bare fetch /home/alice/myproject master:master</tt></pre>
498 </div></div>
499 <div class="paragraph"><p>Next, give every team member read/write access to this repository. One
500 easy way to do this is to give all the team members ssh access to the
501 machine where the repository is hosted. If you don’t want to give them a
502 full shell on the machine, there is a restricted shell which only allows
505 writable by that group:</p></div>
509 </div></div>
510 <div class="paragraph"><p>Make sure committers have a umask of at most 027, so that the directories
511 they create are writable and searchable by other group members.</p></div>
512 </div>
517 sure it is in your path. Then cd to a checked out CVS working directory
518 of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p></div>
522 </div></div>
525 <div class="paragraph"><p>The import checks out from CVS every revision of every file. Reportedly
526 cvsimport can average some twenty revisions per second, so for a
527 medium-sized project this should not take more than a couple of minutes.
528 Larger projects or remote repositories may take longer.</p></div>
529 <div class="paragraph"><p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
530 CVS branches are stored in git branches with the same names. The most
532 branch, so you can start adding your own changes right away.</p></div>
534 fetch any CVS updates that have been made in the meantime. For this to
535 work, you must not modify the imported branches; instead, create new
536 branches for your own changes, and merge in the imported branches as
537 necessary.</p></div>
539 of the imported directory, as described above. Then treat the imported
540 directory as another development clone for purposes of merging
541 incremental imports.</p></div>
542 </div>
546 points. You can use these, for example, to send all commits to the shared
551 </div>
552 <h2 id="_providing_cvs_access_to_a_git_repository">Providing CVS Access to a git Repository</h2>
554 <div class="paragraph"><p>It is also possible to provide true CVS access to a git repository, so
556 details.</p></div>
557 </div>
560 <div class="paragraph"><p>CVS users are accustomed to giving a group of developers commit access to
561 a common repository. As we’ve seen, this is also possible with git.
562 However, the distributed nature of git allows other development models,
563 and you may want to first consider whether one of them might be a better
564 fit for your project.</p></div>
565 <div class="paragraph"><p>For example, you can choose a single person to maintain the project’s
566 primary public repository. Other developers then clone this repository
567 and each work in their own clone. When they have a series of changes that
568 they’re happy with, they ask the maintainer to pull from the branch
569 containing the changes. The maintainer reviews their changes and pulls
570 them into the primary repository, which other developers pull from as
571 necessary to stay coordinated. The Linux kernel and other projects use
572 variants of this model.</p></div>
573 <div class="paragraph"><p>With a small group, developers may just pull changes from each other’s
574 repositories without the need for a central maintainer.</p></div>
575 </div>
584 </div>
588 </div>
592 </div>
593 </div>
594 </body>
595 </html>