1git for CVS users 2================= 3 4Ok, so you're a CVS user. That's ok, it's a treatable condition, and the 5first step to recovery is admitting you have a problem. The fact that 6you are reading this file means that you may be well on that path 7already. 8 9The thing about CVS is that it absolutely sucks as a source control 10manager, and you'll thus be happy with almost anything else. git, 11however, may be a bit 'too' different (read: "good") for your taste, and 12does a lot of things differently. 13 14One particular suckage of CVS is very hard to work around: CVS is 15basically a tool for tracking 'file' history, while git is a tool for 16tracking 'project' history. This sometimes causes problems if you are 17used to doing very strange things in CVS, in particular if you're doing 18things like making branches of just a subset of the project. git can't 19track that, since git never tracks things on the level of an individual 20file, only on the whole project level. 21 22The good news is that most people don't do that, and in fact most sane 23people think it's a bug in CVS that makes it tag (and check in changes) 24one file at a time. So most projects you'll ever see will use CVS 25'as if' it was sane. In which case you'll find it very easy indeed to 26move over to git. 27 28First off: this is not a git tutorial. See 29link:tutorial.html[Documentation/tutorial.txt] for how git 30actually works. This is more of a random collection of gotcha's 31and notes on converting from CVS to git. 32 33Second: CVS has the notion of a "repository" as opposed to the thing 34that you're actually working in (your working directory, or your 35"checked out tree"). git does not have that notion at all, and all git 36working directories 'are' the repositories. However, you can easily 37emulate the CVS model by having one special "global repository", which 38people can synchronize with. See details later, but in the meantime 39just keep in mind that with git, every checked out working tree will 40have a full revision control history of its own. 41 42 43Importing a CVS archive 44----------------------- 45 46Ok, you have an old project, and you want to at least give git a chance 47to see how it performs. The first thing you want to do (after you've 48gone through the git tutorial, and generally familiarized yourself with 49how to commit stuff etc in git) is to create a git'ified version of your 50CVS archive. 51 52Happily, that's very easy indeed. git will do it for you, although git 53will need the help of a program called "cvsps": 54 55 http://www.cobite.com/cvsps/ 56 57which is not actually related to git at all, but which makes CVS usage 58look almost sane (ie you almost certainly want to have it even if you 59decide to stay with CVS). However, git will want 'at least' version 2.1 60of cvsps (available at the address above), and in fact will currently 61refuse to work with anything else. 62 63Once you've gotten (and installed) cvsps, you may or may not want to get 64any more familiar with it, but make sure it is in your path. After that, 65the magic command line is 66 67 git cvsimport -v -d <cvsroot> -C <destination> <module> 68 69which will do exactly what you'd think it does: it will create a git 70archive of the named CVS module. The new archive will be created in the 71subdirectory named <destination>; it'll be created if it doesn't exist. 72Default is the local directory. 73 74It can take some time to actually do the conversion for a large archive 75since it involves checking out from CVS every revision of every file, 76and the conversion script is reasonably chatty unless you omit the '-v' 77option, but on some not very scientific tests it averaged about twenty 78revisions per second, so a medium-sized project should not take more 79than a couple of minutes. For larger projects or remote repositories, 80the process may take longer. 81 82After the (initial) import is done, the CVS archive's current head 83revision will be checked out -- thus, you can start adding your own 84changes right away. 85 86The import is incremental, i.e. if you call it again next month it'll 87fetch any CVS updates that have been happening in the meantime. The 88cut-off is date-based, so don't change the branches that were imported 89from CVS. 90 91You can merge those updates (or, in fact, a different CVS branch) into 92your main branch: 93 94 git resolve HEAD origin "merge with current CVS HEAD" 95 96The HEAD revision from CVS is named "origin", not "HEAD", because git 97already uses "HEAD". (If you don't like 'origin', use cvsimport's 98'-o' option to change it.) 99 100 101Emulating CVS behaviour 102----------------------- 103 104 105So, by now you are convinced you absolutely want to work with git, but 106at the same time you absolutely have to have a central repository. 107Step back and think again. Okay, you still need a single central 108repository? There are several ways to go about that: 109 1101. Designate a person responsible to pull all branches. Make the 111repository of this person public, and make every team member 112pull regularly from it. 113 1142. Set up a public repository with read/write access for every team 115member. Use "git pull/push" as you used "cvs update/commit". Be 116sure that your repository is up to date before pushing, just 117like you used to do with "cvs commit"; your push will fail if 118what you are pushing is not up to date. 119 1203. Make the repository of every team member public. It is the 121responsibility of each single member to pull from every other 122team member. 123 124 125CVS annotate 126------------ 127 128So, something has gone wrong, and you don't know whom to blame, and 129you're an ex-CVS user and used to do "cvs annotate" to see who caused 130the breakage. You're looking for the "git annotate", and it's just 131claiming not to find such a script. You're annoyed. 132 133Yes, that's right. Core git doesn't do "annotate", although it's 134technically possible, and there are at least two specialized scripts out 135there that can be used to get equivalent information (see the git 136mailing list archives for details). 137 138git has a couple of alternatives, though, that you may find sufficient 139or even superior depending on your use. One is called "git-whatchanged" 140(for obvious reasons) and the other one is called "pickaxe" ("a tool for 141the software archeologist"). 142 143The "git-whatchanged" script is a truly trivial script that can give you 144a good overview of what has changed in a file or a directory (or an 145arbitrary list of files or directories). The "pickaxe" support is an 146additional layer that can be used to further specify exactly what you're 147looking for, if you already know the specific area that changed. 148 149Let's step back a bit and think about the reason why you would 150want to do "cvs annotate a-file.c" to begin with. 151 152You would use "cvs annotate" on a file when you have trouble 153with a function (or even a single "if" statement in a function) 154that happens to be defined in the file, which does not do what 155you want it to do. And you would want to find out why it was 156written that way, because you are about to modify it to suit 157your needs, and at the same time you do not want to break its 158current callers. For that, you are trying to find out why the 159original author did things that way in the original context. 160 161Many times, it may be enough to see the commit log messages of 162commits that touch the file in question, possibly along with the 163patches themselves, like this: 164 165 $ git-whatchanged -p a-file.c 166 167This will show log messages and patches for each commit that 168touches a-file. 169 170This, however, may not be very useful when this file has many 171modifications that are not related to the piece of code you are 172interested in. You would see many log messages and patches that 173do not have anything to do with the piece of code you are 174interested in. As an example, assuming that you have this piece 175of code that you are interested in in the HEAD version: 176 177 if (frotz) { 178 nitfol(); 179 } 180 181you would use git-rev-list and git-diff-tree like this: 182 183 $ git-rev-list HEAD | 184 git-diff-tree --stdin -v -p -S'if (frotz) { 185 nitfol(); 186 }' 187 188We have already talked about the "\--stdin" form of git-diff-tree 189command that reads the list of commits and compares each commit 190with its parents. The git-whatchanged command internally runs 191the equivalent of the above command, and can be used like this: 192 193 $ git-whatchanged -p -S'if (frotz) { 194 nitfol(); 195 }' 196 197When the -S option is used, git-diff-tree command outputs 198differences between two commits only if one tree has the 199specified string in a file and the corresponding file in the 200other tree does not. The above example looks for a commit that 201has the "if" statement in it in a file, but its parent commit 202does not have it in the same shape in the corresponding file (or 203the other way around, where the parent has it and the commit 204does not), and the differences between them are shown, along 205with the commit message (thanks to the -v flag). It does not 206show anything for commits that do not touch this "if" statement. 207 208Also, in the original context, the same statement might have 209appeared at first in a different file and later the file was 210renamed to "a-file.c". CVS annotate would not help you to go 211back across such a rename, but git would still help you in such 212a situation. For that, you can give the -C flag to 213git-diff-tree, like this: 214 215 $ git-whatchanged -p -C -S'if (frotz) { 216 nitfol(); 217 }' 218 219When the -C flag is used, file renames and copies are followed. 220So if the "if" statement in question happens to be in "a-file.c" 221in the current HEAD commit, even if the file was originally 222called "o-file.c" and then renamed in an earlier commit, or if 223the file was created by copying an existing "o-file.c" in an 224earlier commit, you will not lose track. If the "if" statement 225did not change across such a rename or copy, then the commit that 226does rename or copy would not show in the output, and if the 227"if" statement was modified while the file was still called 228"o-file.c", it would find the commit that changed the statement 229when it was in "o-file.c". 230 231NOTE: The current version of "git-diff-tree -C" is not eager 232 enough to find copies, and it will miss the fact that a-file.c 233 was created by copying o-file.c unless o-file.c was somehow 234 changed in the same commit. 235 236You can use the --pickaxe-all flag in addition to the -S flag. 237This causes the differences from all the files contained in 238those two commits, not just the differences between the files 239that contain this changed "if" statement: 240 241 $ git-whatchanged -p -C -S'if (frotz) { 242 nitfol(); 243 }' --pickaxe-all 244 245NOTE: This option is called "--pickaxe-all" because -S 246 option is internally called "pickaxe", a tool for software 247 archaeologists.