logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

gitcvs-migration.7 (9160B)


  1. '\" t
  2. .\" Title: gitcvs-migration
  3. .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
  4. .\" Generator: DocBook XSL Stylesheets v1.79.2 <http://docbook.sf.net/>
  5. .\" Date: 2025-03-14
  6. .\" Manual: Git Manual
  7. .\" Source: Git 2.49.0
  8. .\" Language: English
  9. .\"
  10. .TH "GITCVS\-MIGRATION" "7" "2025-03-14" "Git 2\&.49\&.0" "Git Manual"
  11. .\" -----------------------------------------------------------------
  12. .\" * Define some portability stuff
  13. .\" -----------------------------------------------------------------
  14. .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  15. .\" http://bugs.debian.org/507673
  16. .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
  17. .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  18. .ie \n(.g .ds Aq \(aq
  19. .el .ds Aq '
  20. .\" -----------------------------------------------------------------
  21. .\" * set default formatting
  22. .\" -----------------------------------------------------------------
  23. .\" disable hyphenation
  24. .nh
  25. .\" disable justification (adjust text to left margin only)
  26. .ad l
  27. .\" -----------------------------------------------------------------
  28. .\" * MAIN CONTENT STARTS HERE *
  29. .\" -----------------------------------------------------------------
  30. .SH "NAME"
  31. gitcvs-migration \- Git for CVS users
  32. .SH "SYNOPSIS"
  33. .sp
  34. .nf
  35. \fIgit cvsimport\fR *
  36. .fi
  37. .SH "DESCRIPTION"
  38. .sp
  39. Git differs from CVS in that every working tree contains a repository with a full copy of the project history, and no repository is inherently more important than any other\&. However, you can emulate the CVS model by designating a single shared repository which people can synchronize with; this document explains how to do that\&.
  40. .sp
  41. Some basic familiarity with Git is required\&. Having gone through \fBgittutorial\fR(7) and \fBgitglossary\fR(7) should be sufficient\&.
  42. .SH "DEVELOPING AGAINST A SHARED REPOSITORY"
  43. .sp
  44. Suppose a shared repository is set up in /pub/repo\&.git on the host foo\&.com\&. Then as an individual committer you can clone the shared repository over ssh with:
  45. .sp
  46. .if n \{\
  47. .RS 4
  48. .\}
  49. .nf
  50. $ git clone foo\&.com:/pub/repo\&.git/ my\-project
  51. $ cd my\-project
  52. .fi
  53. .if n \{\
  54. .RE
  55. .\}
  56. .sp
  57. and hack away\&. The equivalent of \fIcvs update\fR is
  58. .sp
  59. .if n \{\
  60. .RS 4
  61. .\}
  62. .nf
  63. $ git pull origin
  64. .fi
  65. .if n \{\
  66. .RE
  67. .\}
  68. .sp
  69. which merges in any work that others might have done since the clone operation\&. If there are uncommitted changes in your working tree, commit them first before running git pull\&.
  70. .if n \{\
  71. .sp
  72. .\}
  73. .RS 4
  74. .it 1 an-trap
  75. .nr an-no-space-flag 1
  76. .nr an-break-flag 1
  77. .br
  78. .ps +1
  79. \fBNote\fR
  80. .ps -1
  81. .br
  82. .sp
  83. The \fIpull\fR command knows where to get updates from because of certain configuration variables that were set by the first \fIgit clone\fR command; see \fBgit\fR \fBconfig\fR \fB\-l\fR and the \fBgit-config\fR(1) man page for details\&.
  84. .sp .5v
  85. .RE
  86. .sp
  87. You can update the shared repository with your changes by first committing your changes, and then using the \fIgit push\fR command:
  88. .sp
  89. .if n \{\
  90. .RS 4
  91. .\}
  92. .nf
  93. $ git push origin master
  94. .fi
  95. .if n \{\
  96. .RE
  97. .\}
  98. .sp
  99. to "push" those commits to the shared repository\&. If someone else has updated the repository more recently, \fIgit push\fR, like \fIcvs commit\fR, will complain, in which case you must pull any changes before attempting the push again\&.
  100. .sp
  101. In the \fIgit push\fR command above we specify the name of the remote branch to update (\fBmaster\fR)\&. If we leave that out, \fIgit push\fR tries to update any branches in the remote repository that have the same name as a branch in the local repository\&. So the last \fIpush\fR can be done with either of:
  102. .sp
  103. .if n \{\
  104. .RS 4
  105. .\}
  106. .nf
  107. $ git push origin
  108. $ git push foo\&.com:/pub/project\&.git/
  109. .fi
  110. .if n \{\
  111. .RE
  112. .\}
  113. .sp
  114. as long as the shared repository does not have any branches other than \fBmaster\fR\&.
  115. .SH "SETTING UP A SHARED REPOSITORY"
  116. .sp
  117. We assume you have already created a Git repository for your project, possibly created from scratch or from a tarball (see \fBgittutorial\fR(7)), or imported from an already existing CVS repository (see the next section)\&.
  118. .sp
  119. Assume your existing repo is at /home/alice/myproject\&. Create a new "bare" repository (a repository without a working tree) and fetch your project into it:
  120. .sp
  121. .if n \{\
  122. .RS 4
  123. .\}
  124. .nf
  125. $ mkdir /pub/my\-repo\&.git
  126. $ cd /pub/my\-repo\&.git
  127. $ git \-\-bare init \-\-shared
  128. $ git \-\-bare fetch /home/alice/myproject master:master
  129. .fi
  130. .if n \{\
  131. .RE
  132. .\}
  133. .sp
  134. Next, give every team member read/write access to this repository\&. One easy way to do this is to give all the team members ssh access to the machine where the repository is hosted\&. If you don\(cqt want to give them a full shell on the machine, there is a restricted shell which only allows users to do Git pushes and pulls; see \fBgit-shell\fR(1)\&.
  135. .sp
  136. Put all the committers in the same group, and make the repository writable by that group:
  137. .sp
  138. .if n \{\
  139. .RS 4
  140. .\}
  141. .nf
  142. $ chgrp \-R $group /pub/my\-repo\&.git
  143. .fi
  144. .if n \{\
  145. .RE
  146. .\}
  147. .sp
  148. Make sure committers have a umask of at most 027, so that the directories they create are writable and searchable by other group members\&.
  149. .SH "IMPORTING A CVS ARCHIVE"
  150. .if n \{\
  151. .sp
  152. .\}
  153. .RS 4
  154. .it 1 an-trap
  155. .nr an-no-space-flag 1
  156. .nr an-break-flag 1
  157. .br
  158. .ps +1
  159. \fBNote\fR
  160. .ps -1
  161. .br
  162. .sp
  163. These instructions use the \fBgit\-cvsimport\fR script which ships with git, but other importers may provide better results\&. See the note in \fBgit-cvsimport\fR(1) for other options\&.
  164. .sp .5v
  165. .RE
  166. .sp
  167. First, install version 2\&.1 or higher of cvsps from \m[blue]\fBhttps://github\&.com/andreyvit/cvsps\fR\m[] and make sure it is in your path\&. Then cd to a checked out CVS working directory of the project you are interested in and run \fBgit-cvsimport\fR(1):
  168. .sp
  169. .if n \{\
  170. .RS 4
  171. .\}
  172. .nf
  173. $ git cvsimport \-C <destination> <module>
  174. .fi
  175. .if n \{\
  176. .RE
  177. .\}
  178. .sp
  179. This puts a Git archive of the named CVS module in the directory <destination>, which will be created if necessary\&.
  180. .sp
  181. The import checks out from CVS every revision of every file\&. Reportedly cvsimport can average some twenty revisions per second, so for a medium\-sized project this should not take more than a couple of minutes\&. Larger projects or remote repositories may take longer\&.
  182. .sp
  183. The main trunk is stored in the Git branch named \fBorigin\fR, and additional CVS branches are stored in Git branches with the same names\&. The most recent version of the main trunk is also left checked out on the \fBmaster\fR branch, so you can start adding your own changes right away\&.
  184. .sp
  185. The import is incremental, so if you call it again next month it will fetch any CVS updates that have been made in the meantime\&. For this to work, you must not modify the imported branches; instead, create new branches for your own changes, and merge in the imported branches as necessary\&.
  186. .sp
  187. If you want a shared repository, you will need to make a bare clone of the imported directory, as described above\&. Then treat the imported directory as another development clone for purposes of merging incremental imports\&.
  188. .SH "ADVANCED SHARED REPOSITORY MANAGEMENT"
  189. .sp
  190. Git allows you to specify scripts called "hooks" to be run at certain points\&. You can use these, for example, to send all commits to the shared repository to a mailing list\&. See \fBgithooks\fR(5)\&.
  191. .sp
  192. You can enforce finer grained permissions using update hooks\&. See \m[blue]\fBControlling access to branches using update hooks\fR\m[]\&\s-2\u[1]\d\s+2\&.
  193. .SH "PROVIDING CVS ACCESS TO A GIT REPOSITORY"
  194. .sp
  195. It is also possible to provide true CVS access to a Git repository, so that developers can still use CVS; see \fBgit-cvsserver\fR(1) for details\&.
  196. .SH "ALTERNATIVE DEVELOPMENT MODELS"
  197. .sp
  198. CVS users are accustomed to giving a group of developers commit access to a common repository\&. As we\(cqve seen, this is also possible with Git\&. However, the distributed nature of Git allows other development models, and you may want to first consider whether one of them might be a better fit for your project\&.
  199. .sp
  200. For example, you can choose a single person to maintain the project\(cqs primary public repository\&. Other developers then clone this repository and each work in their own clone\&. When they have a series of changes that they\(cqre happy with, they ask the maintainer to pull from the branch containing the changes\&. The maintainer reviews their changes and pulls them into the primary repository, which other developers pull from as necessary to stay coordinated\&. The Linux kernel and other projects use variants of this model\&.
  201. .sp
  202. With a small group, developers may just pull changes from each other\(cqs repositories without the need for a central maintainer\&.
  203. .SH "SEE ALSO"
  204. .sp
  205. \fBgittutorial\fR(7), \fBgittutorial-2\fR(7), \fBgitcore-tutorial\fR(7), \fBgitglossary\fR(7), \fBgiteveryday\fR(7), \m[blue]\fBThe Git User\(cqs Manual\fR\m[]\&\s-2\u[2]\d\s+2
  206. .SH "GIT"
  207. .sp
  208. Part of the \fBgit\fR(1) suite
  209. .SH "NOTES"
  210. .IP " 1." 4
  211. Controlling access to branches using update hooks
  212. .RS 4
  213. \%git-htmldocs/howto/update-hook-example.html
  214. .RE
  215. .IP " 2." 4
  216. The Git User\(cqs Manual
  217. .RS 4
  218. \%git-htmldocs/user-manual.html
  219. .RE