| blob | 3735b24670dbdb1ce33a365ab11a16874074c0e7 |
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 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 gitcvs-migration(7) Manual Page
574 </h1>
577 <p>gitcvs-migration -
578 git for CVS users
579 </p>
580 </div>
581 </div>
588 </div></div>
589 </div>
592 <div class="paragraph"><p>Git differs from CVS in that every working tree contains a repository with
593 a full copy of the project history, and no repository is inherently more
594 important than any other. However, you can emulate the CVS model by
595 designating a single shared repository which people can synchronize with;
596 this document explains how to do that.</p></div>
600 </div>
604 foo.com. Then as an individual committer you can clone the shared
605 repository over ssh with:</p></div>
608 <pre><tt>$ git clone foo.com:/pub/repo.git/ my-project
609 $ cd my-project</tt></pre>
610 </div></div>
615 </div></div>
617 operation. If there are uncommitted changes in your working tree, commit
618 them first before running git pull.</p></div>
620 <table><tr>
623 </td>
625 <div class="paragraph"><p>The <em>pull</em> command knows where to get updates from because of certain
628 page for details.</p></div>
629 </td>
630 </tr></table>
631 </div>
632 <div class="paragraph"><p>You can update the shared repository with your changes by first committing
637 </div></div>
640 complain, in which case you must pull any changes before attempting the
641 push again.</p></div>
642 <div class="paragraph"><p>In the <em>git push</em> command above we specify the name of the remote branch
644 any branches in the remote repository that have the same name as a branch
648 <pre><tt>$ git push origin
649 $ git push foo.com:/pub/project.git/</tt></pre>
650 </div></div>
653 </div>
657 possibly created from scratch or from a tarball (see
659 repository (see the next section).</p></div>
660 <div class="paragraph"><p>Assume your existing repo is at /home/alice/myproject. Create a new "bare"
661 repository (a repository without a working tree) and fetch your project into
662 it:</p></div>
665 <pre><tt>$ mkdir /pub/my-repo.git
666 $ cd /pub/my-repo.git
667 $ git --bare init --shared
668 $ git --bare fetch /home/alice/myproject master:master</tt></pre>
669 </div></div>
670 <div class="paragraph"><p>Next, give every team member read/write access to this repository. One
671 easy way to do this is to give all the team members ssh access to the
672 machine where the repository is hosted. If you don’t want to give them a
673 full shell on the machine, there is a restricted shell which only allows
676 writable by that group:</p></div>
680 </div></div>
681 <div class="paragraph"><p>Make sure committers have a umask of at most 027, so that the directories
682 they create are writable and searchable by other group members.</p></div>
683 </div>
688 sure it is in your path. Then cd to a checked out CVS working directory
689 of the project you are interested in and run <a href="git-cvsimport.html">git-cvsimport(1)</a>:</p></div>
693 </div></div>
696 <div class="paragraph"><p>The import checks out from CVS every revision of every file. Reportedly
697 cvsimport can average some twenty revisions per second, so for a
698 medium-sized project this should not take more than a couple of minutes.
699 Larger projects or remote repositories may take longer.</p></div>
700 <div class="paragraph"><p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
701 CVS branches are stored in git branches with the same names. The most
703 branch, so you can start adding your own changes right away.</p></div>
705 fetch any CVS updates that have been made in the meantime. For this to
706 work, you must not modify the imported branches; instead, create new
707 branches for your own changes, and merge in the imported branches as
708 necessary.</p></div>
710 of the imported directory, as described above. Then treat the imported
711 directory as another development clone for purposes of merging
712 incremental imports.</p></div>
713 </div>
717 points. You can use these, for example, to send all commits to the shared
722 </div>
723 <h2 id="_providing_cvs_access_to_a_git_repository">Providing CVS Access to a git Repository</h2>
725 <div class="paragraph"><p>It is also possible to provide true CVS access to a git repository, so
727 details.</p></div>
728 </div>
731 <div class="paragraph"><p>CVS users are accustomed to giving a group of developers commit access to
732 a common repository. As we’ve seen, this is also possible with git.
733 However, the distributed nature of git allows other development models,
734 and you may want to first consider whether one of them might be a better
735 fit for your project.</p></div>
736 <div class="paragraph"><p>For example, you can choose a single person to maintain the project’s
737 primary public repository. Other developers then clone this repository
738 and each work in their own clone. When they have a series of changes that
739 they’re happy with, they ask the maintainer to pull from the branch
740 containing the changes. The maintainer reviews their changes and pulls
741 them into the primary repository, which other developers pull from as
742 necessary to stay coordinated. The Linux kernel and other projects use
743 variants of this model.</p></div>
744 <div class="paragraph"><p>With a small group, developers may just pull changes from each other’s
745 repositories without the need for a central maintainer.</p></div>
746 </div>
755 </div>
759 </div>
760 </div>
765 </div>
766 </div>
767 </body>
768 </html>