| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
| 2 | "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> |
| 4 | <head> |
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> |
| 6 | <meta name="generator" content="AsciiDoc 7.0.1" /> |
| 7 | <style type="text/css"> |
| 8 | /* Debug borders */ |
| 9 | p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { |
| 10 | /* |
| 11 | border: 1px solid red; |
| 12 | */ |
| 13 | } |
| 14 | |
| 15 | body { |
| 16 | margin: 1em 5% 1em 5%; |
| 17 | } |
| 18 | |
| 19 | a { color: blue; } |
| 20 | a:visited { color: fuchsia; } |
| 21 | |
| 22 | em { |
| 23 | font-style: italic; |
| 24 | } |
| 25 | |
| 26 | strong { |
| 27 | font-weight: bold; |
| 28 | } |
| 29 | |
| 30 | tt { |
| 31 | color: navy; |
| 32 | } |
| 33 | |
| 34 | h1, h2, h3, h4, h5, h6 { |
| 35 | color: #527bbd; |
| 36 | font-family: sans-serif; |
| 37 | margin-top: 1.2em; |
| 38 | margin-bottom: 0.5em; |
| 39 | line-height: 1.3; |
| 40 | } |
| 41 | |
| 42 | h1 { |
| 43 | border-bottom: 2px solid silver; |
| 44 | } |
| 45 | h2 { |
| 46 | border-bottom: 2px solid silver; |
| 47 | padding-top: 0.5em; |
| 48 | } |
| 49 | |
| 50 | div.sectionbody { |
| 51 | font-family: serif; |
| 52 | margin-left: 0; |
| 53 | } |
| 54 | |
| 55 | hr { |
| 56 | border: 1px solid silver; |
| 57 | } |
| 58 | |
| 59 | p { |
| 60 | margin-top: 0.5em; |
| 61 | margin-bottom: 0.5em; |
| 62 | } |
| 63 | |
| 64 | pre { |
| 65 | padding: 0; |
| 66 | margin: 0; |
| 67 | } |
| 68 | |
| 69 | span#author { |
| 70 | color: #527bbd; |
| 71 | font-family: sans-serif; |
| 72 | font-weight: bold; |
| 73 | font-size: 1.2em; |
| 74 | } |
| 75 | span#email { |
| 76 | } |
| 77 | span#revision { |
| 78 | font-family: sans-serif; |
| 79 | } |
| 80 | |
| 81 | div#footer { |
| 82 | font-family: sans-serif; |
| 83 | font-size: small; |
| 84 | border-top: 2px solid silver; |
| 85 | padding-top: 0.5em; |
| 86 | margin-top: 4.0em; |
| 87 | } |
| 88 | div#footer-text { |
| 89 | float: left; |
| 90 | padding-bottom: 0.5em; |
| 91 | } |
| 92 | div#footer-badges { |
| 93 | float: right; |
| 94 | padding-bottom: 0.5em; |
| 95 | } |
| 96 | |
| 97 | div#preamble, |
| 98 | div.tableblock, div.imageblock, div.exampleblock, div.verseblock, |
| 99 | div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, |
| 100 | div.admonitionblock { |
| 101 | margin-right: 10%; |
| 102 | margin-top: 1.5em; |
| 103 | margin-bottom: 1.5em; |
| 104 | } |
| 105 | div.admonitionblock { |
| 106 | margin-top: 2.5em; |
| 107 | margin-bottom: 2.5em; |
| 108 | } |
| 109 | |
| 110 | div.content { /* Block element content. */ |
| 111 | padding: 0; |
| 112 | } |
| 113 | |
| 114 | /* Block element titles. */ |
| 115 | div.title, caption.title { |
| 116 | font-family: sans-serif; |
| 117 | font-weight: bold; |
| 118 | text-align: left; |
| 119 | margin-top: 1.0em; |
| 120 | margin-bottom: 0.5em; |
| 121 | } |
| 122 | div.title + * { |
| 123 | margin-top: 0; |
| 124 | } |
| 125 | |
| 126 | td div.title:first-child { |
| 127 | margin-top: 0.0em; |
| 128 | } |
| 129 | div.content div.title:first-child { |
| 130 | margin-top: 0.0em; |
| 131 | } |
| 132 | div.content + div.title { |
| 133 | margin-top: 0.0em; |
| 134 | } |
| 135 | |
| 136 | div.sidebarblock > div.content { |
| 137 | background: #ffffee; |
| 138 | border: 1px solid silver; |
| 139 | padding: 0.5em; |
| 140 | } |
| 141 | |
| 142 | div.listingblock > div.content { |
| 143 | border: 1px solid silver; |
| 144 | background: #f4f4f4; |
| 145 | padding: 0.5em; |
| 146 | } |
| 147 | |
| 148 | div.quoteblock > div.content { |
| 149 | padding-left: 2.0em; |
| 150 | } |
| 151 | div.quoteblock .attribution { |
| 152 | text-align: right; |
| 153 | } |
| 154 | |
| 155 | div.admonitionblock .icon { |
| 156 | vertical-align: top; |
| 157 | font-size: 1.1em; |
| 158 | font-weight: bold; |
| 159 | text-decoration: underline; |
| 160 | color: #527bbd; |
| 161 | padding-right: 0.5em; |
| 162 | } |
| 163 | div.admonitionblock td.content { |
| 164 | padding-left: 0.5em; |
| 165 | border-left: 2px solid silver; |
| 166 | } |
| 167 | |
| 168 | div.exampleblock > div.content { |
| 169 | border-left: 2px solid silver; |
| 170 | padding: 0.5em; |
| 171 | } |
| 172 | |
| 173 | div.verseblock div.content { |
| 174 | white-space: pre; |
| 175 | } |
| 176 | |
| 177 | div.imageblock div.content { padding-left: 0; } |
| 178 | div.imageblock img { border: 1px solid silver; } |
| 179 | span.image img { border-style: none; } |
| 180 | |
| 181 | dl { |
| 182 | margin-top: 0.8em; |
| 183 | margin-bottom: 0.8em; |
| 184 | } |
| 185 | dt { |
| 186 | margin-top: 0.5em; |
| 187 | margin-bottom: 0; |
| 188 | font-style: italic; |
| 189 | } |
| 190 | dd > *:first-child { |
| 191 | margin-top: 0; |
| 192 | } |
| 193 | |
| 194 | ul, ol { |
| 195 | list-style-position: outside; |
| 196 | } |
| 197 | ol.olist2 { |
| 198 | list-style-type: lower-alpha; |
| 199 | } |
| 200 | |
| 201 | div.tableblock > table { |
| 202 | border-color: #527bbd; |
| 203 | border-width: 3px; |
| 204 | } |
| 205 | thead { |
| 206 | font-family: sans-serif; |
| 207 | font-weight: bold; |
| 208 | } |
| 209 | tfoot { |
| 210 | font-weight: bold; |
| 211 | } |
| 212 | |
| 213 | div.hlist { |
| 214 | margin-top: 0.8em; |
| 215 | margin-bottom: 0.8em; |
| 216 | } |
| 217 | td.hlist1 { |
| 218 | vertical-align: top; |
| 219 | font-style: italic; |
| 220 | padding-right: 0.8em; |
| 221 | } |
| 222 | td.hlist2 { |
| 223 | vertical-align: top; |
| 224 | } |
| 225 | |
| 226 | @media print { |
| 227 | div#footer-badges { display: none; } |
| 228 | } |
| 229 | /* Workarounds for IE6's broken and incomplete CSS2. */ |
| 230 | |
| 231 | div.sidebar-content { |
| 232 | background: #ffffee; |
| 233 | border: 1px solid silver; |
| 234 | padding: 0.5em; |
| 235 | } |
| 236 | div.sidebar-title, div.image-title { |
| 237 | font-family: sans-serif; |
| 238 | font-weight: bold; |
| 239 | margin-top: 0.0em; |
| 240 | margin-bottom: 0.5em; |
| 241 | } |
| 242 | |
| 243 | div.listingblock div.content { |
| 244 | border: 1px solid silver; |
| 245 | background: #f4f4f4; |
| 246 | padding: 0.5em; |
| 247 | } |
| 248 | |
| 249 | div.quoteblock-content { |
| 250 | padding-left: 2.0em; |
| 251 | } |
| 252 | |
| 253 | div.exampleblock-content { |
| 254 | border-left: 2px solid silver; |
| 255 | padding-left: 0.5em; |
| 256 | } |
| 257 | </style> |
| 258 | <title>git for CVS users</title> |
| 259 | </head> |
| 260 | <body> |
| 261 | <div id="header"> |
| 262 | <h1>git for CVS users</h1> |
| 263 | </div> |
| 264 | <div id="preamble"> |
| 265 | <div class="sectionbody"> |
| 266 | <p>Ok, so you're a CVS user. That's ok, it's a treatable condition, and the |
| 267 | first step to recovery is admitting you have a problem. The fact that |
| 268 | you are reading this file means that you may be well on that path |
| 269 | already.</p> |
| 270 | <p>The thing about CVS is that it absolutely sucks as a source control |
| 271 | manager, and you'll thus be happy with almost anything else. git, |
| 272 | however, may be a bit <em>too</em> different (read: "good") for your taste, and |
| 273 | does a lot of things differently.</p> |
| 274 | <p>One particular suckage of CVS is very hard to work around: CVS is |
| 275 | basically a tool for tracking <em>file</em> history, while git is a tool for |
| 276 | tracking <em>project</em> history. This sometimes causes problems if you are |
| 277 | used to doing very strange things in CVS, in particular if you're doing |
| 278 | things like making branches of just a subset of the project. git can't |
| 279 | track that, since git never tracks things on the level of an individual |
| 280 | file, only on the whole project level.</p> |
| 281 | <p>The good news is that most people don't do that, and in fact most sane |
| 282 | people think it's a bug in CVS that makes it tag (and check in changes) |
| 283 | one file at a time. So most projects you'll ever see will use CVS |
| 284 | <em>as if</em> it was sane. In which case you'll find it very easy indeed to |
| 285 | move over to git.</p> |
| 286 | <p>First off: this is not a git tutorial. See |
| 287 | <a href="tutorial.html">Documentation/tutorial.txt</a> for how git |
| 288 | actually works. This is more of a random collection of gotcha's |
| 289 | and notes on converting from CVS to git.</p> |
| 290 | <p>Second: CVS has the notion of a "repository" as opposed to the thing |
| 291 | that you're actually working in (your working directory, or your |
| 292 | "checked out tree"). git does not have that notion at all, and all git |
| 293 | working directories <em>are</em> the repositories. However, you can easily |
| 294 | emulate the CVS model by having one special "global repository", which |
| 295 | people can synchronize with. See details later, but in the meantime |
| 296 | just keep in mind that with git, every checked out working tree will |
| 297 | have a full revision control history of its own.</p> |
| 298 | </div> |
| 299 | </div> |
| 300 | <h2>Importing a CVS archive</h2> |
| 301 | <div class="sectionbody"> |
| 302 | <p>Ok, you have an old project, and you want to at least give git a chance |
| 303 | to see how it performs. The first thing you want to do (after you've |
| 304 | gone through the git tutorial, and generally familiarized yourself with |
| 305 | how to commit stuff etc in git) is to create a git'ified version of your |
| 306 | CVS archive.</p> |
| 307 | <p>Happily, that's very easy indeed. git will do it for you, although git |
| 308 | will need the help of a program called "cvsps":</p> |
| 309 | <div class="literalblock"> |
| 310 | <div class="content"> |
| 311 | <pre><tt>http://www.cobite.com/cvsps/</tt></pre> |
| 312 | </div></div> |
| 313 | <p>which is not actually related to git at all, but which makes CVS usage |
| 314 | look almost sane (ie you almost certainly want to have it even if you |
| 315 | decide to stay with CVS). However, git will want <em>at least</em> version 2.1 |
| 316 | of cvsps (available at the address above), and in fact will currently |
| 317 | refuse to work with anything else.</p> |
| 318 | <p>Once you've gotten (and installed) cvsps, you may or may not want to get |
| 319 | any more familiar with it, but make sure it is in your path. After that, |
| 320 | the magic command line is</p> |
| 321 | <div class="literalblock"> |
| 322 | <div class="content"> |
| 323 | <pre><tt>git cvsimport -v -d <cvsroot> -C <destination> <module></tt></pre> |
| 324 | </div></div> |
| 325 | <p>which will do exactly what you'd think it does: it will create a git |
| 326 | archive of the named CVS module. The new archive will be created in the |
| 327 | subdirectory named <destination>; it'll be created if it doesn't exist. |
| 328 | Default is the local directory.</p> |
| 329 | <p>It can take some time to actually do the conversion for a large archive |
| 330 | since it involves checking out from CVS every revision of every file, |
| 331 | and the conversion script is reasonably chatty unless you omit the <em>-v</em> |
| 332 | option, but on some not very scientific tests it averaged about twenty |
| 333 | revisions per second, so a medium-sized project should not take more |
| 334 | than a couple of minutes. For larger projects or remote repositories, |
| 335 | the process may take longer.</p> |
| 336 | <p>After the (initial) import is done, the CVS archive's current head |
| 337 | revision will be checked out — thus, you can start adding your own |
| 338 | changes right away.</p> |
| 339 | <p>The import is incremental, i.e. if you call it again next month it'll |
| 340 | fetch any CVS updates that have been happening in the meantime. The |
| 341 | cut-off is date-based, so don't change the branches that were imported |
| 342 | from CVS.</p> |
| 343 | <p>You can merge those updates (or, in fact, a different CVS branch) into |
| 344 | your main branch:</p> |
| 345 | <div class="literalblock"> |
| 346 | <div class="content"> |
| 347 | <pre><tt>git resolve HEAD origin "merge with current CVS HEAD"</tt></pre> |
| 348 | </div></div> |
| 349 | <p>The HEAD revision from CVS is named "origin", not "HEAD", because git |
| 350 | already uses "HEAD". (If you don't like <em>origin</em>, use cvsimport's |
| 351 | <em>-o</em> option to change it.)</p> |
| 352 | </div> |
| 353 | <h2>Emulating CVS behaviour</h2> |
| 354 | <div class="sectionbody"> |
| 355 | <p>So, by now you are convinced you absolutely want to work with git, but |
| 356 | at the same time you absolutely have to have a central repository. |
| 357 | Step back and think again. Okay, you still need a single central |
| 358 | repository? There are several ways to go about that:</p> |
| 359 | <ol> |
| 360 | <li> |
| 361 | <p> |
| 362 | Designate a person responsible to pull all branches. Make the |
| 363 | repository of this person public, and make every team member |
| 364 | pull regularly from it. |
| 365 | </p> |
| 366 | </li> |
| 367 | <li> |
| 368 | <p> |
| 369 | Set up a public repository with read/write access for every team |
| 370 | member. Use "git pull/push" as you used "cvs update/commit". Be |
| 371 | sure that your repository is up to date before pushing, just |
| 372 | like you used to do with "cvs commit"; your push will fail if |
| 373 | what you are pushing is not up to date. |
| 374 | </p> |
| 375 | </li> |
| 376 | <li> |
| 377 | <p> |
| 378 | Make the repository of every team member public. It is the |
| 379 | responsibility of each single member to pull from every other |
| 380 | team member. |
| 381 | </p> |
| 382 | </li> |
| 383 | </ol> |
| 384 | </div> |
| 385 | <h2>CVS annotate</h2> |
| 386 | <div class="sectionbody"> |
| 387 | <p>So, something has gone wrong, and you don't know whom to blame, and |
| 388 | you're an ex-CVS user and used to do "cvs annotate" to see who caused |
| 389 | the breakage. You're looking for the "git annotate", and it's just |
| 390 | claiming not to find such a script. You're annoyed.</p> |
| 391 | <p>Yes, that's right. Core git doesn't do "annotate", although it's |
| 392 | technically possible, and there are at least two specialized scripts out |
| 393 | there that can be used to get equivalent information (see the git |
| 394 | mailing list archives for details).</p> |
| 395 | <p>git has a couple of alternatives, though, that you may find sufficient |
| 396 | or even superior depending on your use. One is called "git-whatchanged" |
| 397 | (for obvious reasons) and the other one is called "pickaxe" ("a tool for |
| Junio C Hamano | 235a91e | 2006-01-07 01:13:58 | [diff] [blame^] | 398 | the software archaeologist").</p> |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 399 | <p>The "git-whatchanged" script is a truly trivial script that can give you |
| 400 | a good overview of what has changed in a file or a directory (or an |
| 401 | arbitrary list of files or directories). The "pickaxe" support is an |
| 402 | additional layer that can be used to further specify exactly what you're |
| 403 | looking for, if you already know the specific area that changed.</p> |
| 404 | <p>Let's step back a bit and think about the reason why you would |
| 405 | want to do "cvs annotate a-file.c" to begin with.</p> |
| 406 | <p>You would use "cvs annotate" on a file when you have trouble |
| 407 | with a function (or even a single "if" statement in a function) |
| 408 | that happens to be defined in the file, which does not do what |
| 409 | you want it to do. And you would want to find out why it was |
| 410 | written that way, because you are about to modify it to suit |
| 411 | your needs, and at the same time you do not want to break its |
| 412 | current callers. For that, you are trying to find out why the |
| 413 | original author did things that way in the original context.</p> |
| 414 | <p>Many times, it may be enough to see the commit log messages of |
| 415 | commits that touch the file in question, possibly along with the |
| 416 | patches themselves, like this:</p> |
| 417 | <div class="literalblock"> |
| 418 | <div class="content"> |
| 419 | <pre><tt>$ git-whatchanged -p a-file.c</tt></pre> |
| 420 | </div></div> |
| 421 | <p>This will show log messages and patches for each commit that |
| 422 | touches a-file.</p> |
| 423 | <p>This, however, may not be very useful when this file has many |
| 424 | modifications that are not related to the piece of code you are |
| 425 | interested in. You would see many log messages and patches that |
| 426 | do not have anything to do with the piece of code you are |
| 427 | interested in. As an example, assuming that you have this piece |
| 428 | of code that you are interested in in the HEAD version:</p> |
| 429 | <div class="literalblock"> |
| 430 | <div class="content"> |
| 431 | <pre><tt>if (frotz) { |
| 432 | nitfol(); |
| 433 | }</tt></pre> |
| 434 | </div></div> |
| 435 | <p>you would use git-rev-list and git-diff-tree like this:</p> |
| 436 | <div class="literalblock"> |
| 437 | <div class="content"> |
| 438 | <pre><tt>$ git-rev-list HEAD | |
| 439 | git-diff-tree --stdin -v -p -S'if (frotz) { |
| 440 | nitfol(); |
| 441 | }'</tt></pre> |
| 442 | </div></div> |
| 443 | <p>We have already talked about the "--stdin" form of git-diff-tree |
| 444 | command that reads the list of commits and compares each commit |
| 445 | with its parents (otherwise you should go back and read the tutorial). |
| 446 | The git-whatchanged command internally runs |
| 447 | the equivalent of the above command, and can be used like this:</p> |
| 448 | <div class="literalblock"> |
| 449 | <div class="content"> |
| 450 | <pre><tt>$ git-whatchanged -p -S'if (frotz) { |
| 451 | nitfol(); |
| 452 | }'</tt></pre> |
| 453 | </div></div> |
| 454 | <p>When the -S option is used, git-diff-tree command outputs |
| 455 | differences between two commits only if one tree has the |
| 456 | specified string in a file and the corresponding file in the |
| 457 | other tree does not. The above example looks for a commit that |
| 458 | has the "if" statement in it in a file, but its parent commit |
| 459 | does not have it in the same shape in the corresponding file (or |
| 460 | the other way around, where the parent has it and the commit |
| 461 | does not), and the differences between them are shown, along |
| 462 | with the commit message (thanks to the -v flag). It does not |
| 463 | show anything for commits that do not touch this "if" statement.</p> |
| 464 | <p>Also, in the original context, the same statement might have |
| 465 | appeared at first in a different file and later the file was |
| 466 | renamed to "a-file.c". CVS annotate would not help you to go |
| 467 | back across such a rename, but git would still help you in such |
| 468 | a situation. For that, you can give the -C flag to |
| 469 | git-diff-tree, like this:</p> |
| 470 | <div class="literalblock"> |
| 471 | <div class="content"> |
| 472 | <pre><tt>$ git-whatchanged -p -C -S'if (frotz) { |
| 473 | nitfol(); |
| 474 | }'</tt></pre> |
| 475 | </div></div> |
| 476 | <p>When the -C flag is used, file renames and copies are followed. |
| 477 | So if the "if" statement in question happens to be in "a-file.c" |
| 478 | in the current HEAD commit, even if the file was originally |
| 479 | called "o-file.c" and then renamed in an earlier commit, or if |
| 480 | the file was created by copying an existing "o-file.c" in an |
| 481 | earlier commit, you will not lose track. If the "if" statement |
| 482 | did not change across such a rename or copy, then the commit that |
| 483 | does rename or copy would not show in the output, and if the |
| 484 | "if" statement was modified while the file was still called |
| 485 | "o-file.c", it would find the commit that changed the statement |
| 486 | when it was in "o-file.c".</p> |
| 487 | <div class="admonitionblock"> |
| 488 | <table><tr> |
| 489 | <td class="icon"> |
| 490 | <div class="title">Note</div> |
| 491 | </td> |
| 492 | <td class="content">The current version of "git-diff-tree -C" is not eager |
| 493 | enough to find copies, and it will miss the fact that a-file.c |
| 494 | was created by copying o-file.c unless o-file.c was somehow |
| 495 | changed in the same commit.</td> |
| 496 | </tr></table> |
| 497 | </div> |
| 498 | <p>You can use the —pickaxe-all flag in addition to the -S flag. |
| 499 | This causes the differences from all the files contained in |
| 500 | those two commits, not just the differences between the files |
| 501 | that contain this changed "if" statement:</p> |
| 502 | <div class="literalblock"> |
| 503 | <div class="content"> |
| 504 | <pre><tt>$ git-whatchanged -p -C -S'if (frotz) { |
| 505 | nitfol(); |
| 506 | }' --pickaxe-all</tt></pre> |
| 507 | </div></div> |
| 508 | <div class="admonitionblock"> |
| 509 | <table><tr> |
| 510 | <td class="icon"> |
| 511 | <div class="title">Note</div> |
| 512 | </td> |
| 513 | <td class="content">This option is called "—pickaxe-all" because -S |
| 514 | option is internally called "pickaxe", a tool for software |
| 515 | archaeologists.</td> |
| 516 | </tr></table> |
| 517 | </div> |
| 518 | </div> |
| 519 | <div id="footer"> |
| 520 | <div id="footer-text"> |
| Junio C Hamano | 235a91e | 2006-01-07 01:13:58 | [diff] [blame^] | 521 | Last updated 06-Jan-2006 17:12:56 PDT |
| Junio C Hamano | 1a4e841 | 2005-12-27 08:17:23 | [diff] [blame] | 522 | </div> |
| 523 | </div> |
| 524 | </body> |
| 525 | </html> |
