| 1 | =for comment |
| 2 | Consistent formatting of this file is achieved with: |
| 3 | perl ./Porting/podtidy pod/perlrepository.pod |
| 4 | |
| 5 | =head1 NAME |
| 6 | |
| 7 | perlrepository - Using the Perl source repository |
| 8 | |
| 9 | =head1 SYNOPSIS |
| 10 | |
| 11 | All of Perl's source code is kept centrally in a Git repository at |
| 12 | I<perl5.git.perl.org>. The repository contains many Perl revisions from |
| 13 | Perl 1 onwards and all the revisions from Perforce, the version control |
| 14 | system we were using previously. This repository is accessible in |
| 15 | different ways. |
| 16 | |
| 17 | The full repository takes up about 80MB of disk space. A check out of |
| 18 | the blead branch (that is, the main development branch, which contains |
| 19 | bleadperl, the development version of perl 5) takes up about 160MB of |
| 20 | disk space (including the repository). A build of bleadperl takes up |
| 21 | about 200MB (including the repository and the check out). |
| 22 | |
| 23 | =head1 GETTING ACCESS TO THE REPOSITORY |
| 24 | |
| 25 | =head2 READ ACCESS VIA THE WEB |
| 26 | |
| 27 | You may access the repository over the web. This allows you to browse |
| 28 | the tree, see recent commits, subscribe to RSS feeds for the changes, |
| 29 | search for particular commits and more. You may access it at: |
| 30 | |
| 31 | http://perl5.git.perl.org/perl.git |
| 32 | |
| 33 | A mirror of the repository is found at: |
| 34 | |
| 35 | http://github.com/github/perl |
| 36 | |
| 37 | =head2 READ ACCESS VIA GIT |
| 38 | |
| 39 | You will need a copy of Git for your computer. You can fetch a copy of |
| 40 | the repository using the Git protocol (which uses port 9418): |
| 41 | |
| 42 | git clone git://perl5.git.perl.org/perl.git perl-git |
| 43 | |
| 44 | This clones the repository and makes a local copy in the F<perl-git> |
| 45 | directory. |
| 46 | |
| 47 | If your local network does not allow you to use port 9418, then you can |
| 48 | fetch a copy of the repository over HTTP (this is slower): |
| 49 | |
| 50 | git clone http://perl5.git.perl.org/perl.git perl-http |
| 51 | |
| 52 | This clones the repository and makes a local copy in the F<perl-http> |
| 53 | directory. |
| 54 | |
| 55 | =head2 WRITE ACCESS TO THE REPOSITORY |
| 56 | |
| 57 | If you are a committer, then you can fetch a copy of the repository |
| 58 | that you can push back on with: |
| 59 | |
| 60 | git clone ssh://perl5.git.perl.org/gitroot/perl.git perl-ssh |
| 61 | |
| 62 | This clones the repository and makes a local copy in the F<perl-ssh> |
| 63 | directory. |
| 64 | |
| 65 | If you cloned using the git protocol, which is faster than ssh, then |
| 66 | you will need to modify your config in order to enable pushing. Edit |
| 67 | F<.git/config> where you will see something like: |
| 68 | |
| 69 | [remote "origin"] |
| 70 | url = git://perl5.git.perl.org/perl.git |
| 71 | |
| 72 | change that to something like this: |
| 73 | |
| 74 | [remote "origin"] |
| 75 | url = ssh://perl5.git.perl.org/gitroot/perl.git |
| 76 | |
| 77 | NOTE: there are symlinks set up so that the /gitroot is optional and |
| 78 | since SSH is the default protocol you can actually shorten the "url" to |
| 79 | C<perl5.git.perl.org:/perl.git>. |
| 80 | |
| 81 | You can also set up your user name and e-mail address. For example |
| 82 | |
| 83 | % git config user.name "Leon Brocard" |
| 84 | % git config user.email acme@astray.com |
| 85 | |
| 86 | It is also possible to keep C<origin> as a git remote, and add a new |
| 87 | remote for ssh access: |
| 88 | |
| 89 | % git remote add camel perl5.git.perl.org:/perl.git |
| 90 | |
| 91 | This allows you to update your local repository by pulling from |
| 92 | C<origin>, which is faster and doesn't require you to authenticate, and |
| 93 | to push your changes back with the C<camel> remote: |
| 94 | |
| 95 | % git fetch camel |
| 96 | % git push camel |
| 97 | |
| 98 | The C<fetch> command just updates the C<camel> refs, as the objects |
| 99 | themselves should have been fetched when pulling from C<origin>. |
| 100 | |
| 101 | The committers have access to 2 servers that serve perl5.git.perl.org. |
| 102 | One is camel.booking.com, which is the 'master' repository. The |
| 103 | perl5.git.perl.org IP address also lives on this machine. The second |
| 104 | one is dromedary.booking.com, which can be used for general testing and |
| 105 | development. Dromedary syncs the git tree from camel every few minutes, |
| 106 | you should not push there. Both machines also have a full CPAN mirror. |
| 107 | To share files with the general public, dromedary serves your |
| 108 | ~/public_html/ as http://users.perl5.git.perl.org/~yourlogin/ |
| 109 | |
| 110 | =head1 OVERVIEW OF THE REPOSITORY |
| 111 | |
| 112 | Once you have changed into the repository directory, you can inspect |
| 113 | it. |
| 114 | |
| 115 | After a clone the repository will contain a single local branch, which |
| 116 | will be the current branch as well, as indicated by the asterisk. |
| 117 | |
| 118 | % git branch |
| 119 | * blead |
| 120 | |
| 121 | Using the -a switch to C<branch> will also show the remote tracking |
| 122 | branches in the repository: |
| 123 | |
| 124 | % git branch -a |
| 125 | * blead |
| 126 | origin/HEAD |
| 127 | origin/blead |
| 128 | ... |
| 129 | |
| 130 | The branches that begin with "origin" correspond to the "git remote" |
| 131 | that you cloned from (which is named "origin"). Each branch on the |
| 132 | remote will be exactly tracked by theses branches. You should NEVER do |
| 133 | work on these remote tracking branches. You only ever do work in a |
| 134 | local branch. Local branches can be configured to automerge (on pull) |
| 135 | from a designated remote tracking branch. This is the case with the |
| 136 | default branch C<blead> which will be configured to merge from the |
| 137 | remote tracking branch C<origin/blead>. |
| 138 | |
| 139 | You can see recent commits: |
| 140 | |
| 141 | % git log |
| 142 | |
| 143 | And pull new changes from the repository, and update your local |
| 144 | repository (must be clean first) |
| 145 | |
| 146 | % git pull |
| 147 | |
| 148 | Assuming we are on the branch C<blead> immediately after a pull, this |
| 149 | command would be more or less equivalent to: |
| 150 | |
| 151 | % git fetch |
| 152 | % git merge origin/blead |
| 153 | |
| 154 | In fact if you want to update your local repository without touching |
| 155 | your working directory you do: |
| 156 | |
| 157 | % git fetch |
| 158 | |
| 159 | And if you want to update your remote-tracking branches for all defined |
| 160 | remotes simultaneously you can do |
| 161 | |
| 162 | % git remote update |
| 163 | |
| 164 | Neither of these last two commands will update your working directory, |
| 165 | however both will update the remote-tracking branches in your |
| 166 | repository. |
| 167 | |
| 168 | To switch to another branch: |
| 169 | |
| 170 | % git checkout origin/maint-5.8-dor |
| 171 | |
| 172 | To make a local branch of a remote branch: |
| 173 | |
| 174 | % git checkout -b maint-5.10 origin/maint-5.10 |
| 175 | |
| 176 | To switch back to blead: |
| 177 | |
| 178 | % git checkout blead |
| 179 | |
| 180 | =head2 FINDING OUT YOUR STATUS |
| 181 | |
| 182 | The most common git command you will use will probably be |
| 183 | |
| 184 | % git status |
| 185 | |
| 186 | This command will produce as output a description of the current state |
| 187 | of the repository, including modified files and unignored untracked |
| 188 | files, and in addition it will show things like what files have been |
| 189 | staged for the next commit, and usually some useful information about |
| 190 | how to change things. For instance the following: |
| 191 | |
| 192 | $ git status |
| 193 | # On branch blead |
| 194 | # Your branch is ahead of 'origin/blead' by 1 commit. |
| 195 | # |
| 196 | # Changes to be committed: |
| 197 | # (use "git reset HEAD <file>..." to unstage) |
| 198 | # |
| 199 | # modified: pod/perlrepository.pod |
| 200 | # |
| 201 | # Changed but not updated: |
| 202 | # (use "git add <file>..." to update what will be committed) |
| 203 | # |
| 204 | # modified: pod/perlrepository.pod |
| 205 | # |
| 206 | # Untracked files: |
| 207 | # (use "git add <file>..." to include in what will be committed) |
| 208 | # |
| 209 | # deliberate.untracked |
| 210 | |
| 211 | This shows that there were changes to this document staged for commit, |
| 212 | and that there were further changes in the working directory not yet |
| 213 | staged. It also shows that there was an untracked file in the working |
| 214 | directory, and as you can see shows how to change all of this. It also |
| 215 | shows that there is one commit on the working branch C<blead> which has |
| 216 | not been pushed to the C<origin> remote yet. B<NOTE>: that this output |
| 217 | is also what you see as a template if you do not provide a message to |
| 218 | C<git commit>. |
| 219 | |
| 220 | Assuming we commit all the mentioned changes above: |
| 221 | |
| 222 | % git commit -a -m'explain git status and stuff about remotes' |
| 223 | Created commit daf8e63: explain git status and stuff about remotes |
| 224 | 1 files changed, 83 insertions(+), 3 deletions(-) |
| 225 | |
| 226 | We can re-run git status and see something like this: |
| 227 | |
| 228 | % git status |
| 229 | # On branch blead |
| 230 | # Your branch is ahead of 'origin/blead' by 2 commits. |
| 231 | # |
| 232 | # Untracked files: |
| 233 | # (use "git add <file>..." to include in what will be committed) |
| 234 | # |
| 235 | # deliberate.untracked |
| 236 | nothing added to commit but untracked files present (use "git add" to track) |
| 237 | |
| 238 | |
| 239 | When in doubt, before you do anything else, check your status and read |
| 240 | it carefully, many questions are answered directly by the git status |
| 241 | output. |
| 242 | |
| 243 | =head1 SUBMITTING A PATCH |
| 244 | |
| 245 | If you have a patch in mind for Perl, you should first get a copy of |
| 246 | the repository: |
| 247 | |
| 248 | % git clone git://perl5.git.perl.org/perl.git perl-git |
| 249 | |
| 250 | Then change into the directory: |
| 251 | |
| 252 | % cd perl-git |
| 253 | |
| 254 | Alternatively, if you already have a Perl repository, you should ensure |
| 255 | that you're on the I<blead> branch, and your repository is up to date: |
| 256 | |
| 257 | % git checkout blead |
| 258 | % git pull |
| 259 | |
| 260 | It's preferable to patch against the latest blead version, since this |
| 261 | is where new development occurs for all changes other than critical bug |
| 262 | fixes. Critical bug fix patches should be made against the relevant |
| 263 | maint branches, or should be submitted with a note indicating all the |
| 264 | branches where the fix should be applied. |
| 265 | |
| 266 | Now that we have everything up to date, we need to create a temporary |
| 267 | new branch for these changes and switch into it: |
| 268 | |
| 269 | % git checkout -b orange |
| 270 | |
| 271 | which is the short form of |
| 272 | |
| 273 | % git branch orange |
| 274 | % git checkout orange |
| 275 | |
| 276 | Then make your changes. For example, if Leon Brocard changes his name |
| 277 | to Orange Brocard, we should change his name in the AUTHORS file: |
| 278 | |
| 279 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS |
| 280 | |
| 281 | You can see what files are changed: |
| 282 | |
| 283 | % git status |
| 284 | # On branch orange |
| 285 | # Changes to be committed: |
| 286 | # (use "git reset HEAD <file>..." to unstage) |
| 287 | # |
| 288 | # modified: AUTHORS |
| 289 | # |
| 290 | |
| 291 | And you can see the changes: |
| 292 | |
| 293 | % git diff |
| 294 | diff --git a/AUTHORS b/AUTHORS |
| 295 | index 293dd70..722c93e 100644 |
| 296 | --- a/AUTHORS |
| 297 | +++ b/AUTHORS |
| 298 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
| 299 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
| 300 | Leif Huhn <leif@hale.dkstat.com> |
| 301 | Len Johnson <lenjay@ibm.net> |
| 302 | -Leon Brocard <acme@astray.com> |
| 303 | +Orange Brocard <acme@astray.com> |
| 304 | Les Peters <lpeters@aol.net> |
| 305 | Lesley Binks <lesley.binks@gmail.com> |
| 306 | Lincoln D. Stein <lstein@cshl.org> |
| 307 | |
| 308 | Now commit your change locally: |
| 309 | |
| 310 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
| 311 | Created commit 6196c1d: Rename Leon Brocard to Orange Brocard |
| 312 | 1 files changed, 1 insertions(+), 1 deletions(-) |
| 313 | |
| 314 | You can examine your last commit with: |
| 315 | |
| 316 | % git show HEAD |
| 317 | |
| 318 | and if you are not happy with either the description or the patch |
| 319 | itself you can fix it up by editing the files once more and then issue: |
| 320 | |
| 321 | % git commit -a --amend |
| 322 | |
| 323 | Now you should create a patch file for all your local changes: |
| 324 | |
| 325 | % git format-patch origin |
| 326 | 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
| 327 | |
| 328 | You should now send an email to perl5-porters@perl.org with a |
| 329 | description of your changes, and include this patch file as an |
| 330 | attachment. |
| 331 | |
| 332 | If you want to delete your temporary branch, you may do so with: |
| 333 | |
| 334 | % git checkout blead |
| 335 | % git branch -d orange |
| 336 | error: The branch 'orange' is not an ancestor of your current HEAD. |
| 337 | If you are sure you want to delete it, run 'git branch -D orange'. |
| 338 | % git branch -D orange |
| 339 | Deleted branch orange. |
| 340 | |
| 341 | =head2 A note on derived files |
| 342 | |
| 343 | Be aware that many files in the distribution are derivative--avoid |
| 344 | patching them, because git won't see the changes to them, and the build |
| 345 | process will overwrite them. Patch the originals instead. Most |
| 346 | utilities (like perldoc) are in this category, i.e. patch |
| 347 | utils/perldoc.PL rather than utils/perldoc. Similarly, don't create |
| 348 | patches for files under $src_root/ext from their copies found in |
| 349 | $install_root/lib. If you are unsure about the proper location of a |
| 350 | file that may have gotten copied while building the source |
| 351 | distribution, consult the C<MANIFEST>. |
| 352 | |
| 353 | =for XXX |
| 354 | |
| 355 | What should we recommend about binary files now? Do we need anything? |
| 356 | |
| 357 | =head2 Getting your patch accepted |
| 358 | |
| 359 | The first thing you should include with your patch is a description of |
| 360 | the problem that the patch corrects. If it is a code patch (rather |
| 361 | than a documentation patch) you should also include a small test case |
| 362 | that illustrates the bug (a patch to an existing test file is |
| 363 | preferred). |
| 364 | |
| 365 | If you are submitting a code patch there are several other things that |
| 366 | you need to do. |
| 367 | |
| 368 | =over 4 |
| 369 | |
| 370 | =item Comments, Comments, Comments |
| 371 | |
| 372 | Be sure to adequately comment your code. While commenting every line |
| 373 | is unnecessary, anything that takes advantage of side effects of |
| 374 | operators, that creates changes that will be felt outside of the |
| 375 | function being patched, or that others may find confusing should be |
| 376 | documented. If you are going to err, it is better to err on the side |
| 377 | of adding too many comments than too few. |
| 378 | |
| 379 | =item Style |
| 380 | |
| 381 | In general, please follow the particular style of the code you are |
| 382 | patching. |
| 383 | |
| 384 | In particular, follow these general guidelines for patching Perl |
| 385 | sources: |
| 386 | |
| 387 | 8-wide tabs (no exceptions!) |
| 388 | 4-wide indents for code, 2-wide indents for nested CPP #defines |
| 389 | try hard not to exceed 79-columns |
| 390 | ANSI C prototypes |
| 391 | uncuddled elses and "K&R" style for indenting control constructs |
| 392 | no C++ style (//) comments |
| 393 | mark places that need to be revisited with XXX (and revisit often!) |
| 394 | opening brace lines up with "if" when conditional spans multiple |
| 395 | lines; should be at end-of-line otherwise |
| 396 | in function definitions, name starts in column 0 (return value is on |
| 397 | previous line) |
| 398 | single space after keywords that are followed by parens, no space |
| 399 | between function name and following paren |
| 400 | avoid assignments in conditionals, but if they're unavoidable, use |
| 401 | extra paren, e.g. "if (a && (b = c)) ..." |
| 402 | "return foo;" rather than "return(foo);" |
| 403 | "if (!foo) ..." rather than "if (foo == FALSE) ..." etc. |
| 404 | |
| 405 | =item Testsuite |
| 406 | |
| 407 | When submitting a patch you should make every effort to also include an |
| 408 | addition to perl's regression tests to properly exercise your patch. |
| 409 | Your testsuite additions should generally follow these guidelines |
| 410 | (courtesy of Gurusamy Sarathy <gsar@activestate.com>): |
| 411 | |
| 412 | Know what you're testing. Read the docs, and the source. |
| 413 | Tend to fail, not succeed. |
| 414 | Interpret results strictly. |
| 415 | Use unrelated features (this will flush out bizarre interactions). |
| 416 | Use non-standard idioms (otherwise you are not testing TIMTOWTDI). |
| 417 | Avoid using hardcoded test numbers whenever possible (the |
| 418 | EXPECTED/GOT found in t/op/tie.t is much more maintainable, |
| 419 | and gives better failure reports). |
| 420 | Give meaningful error messages when a test fails. |
| 421 | Avoid using qx// and system() unless you are testing for them. If you |
| 422 | do use them, make sure that you cover _all_ perl platforms. |
| 423 | Unlink any temporary files you create. |
| 424 | Promote unforeseen warnings to errors with $SIG{__WARN__}. |
| 425 | Be sure to use the libraries and modules shipped with the version |
| 426 | being tested, not those that were already installed. |
| 427 | Add comments to the code explaining what you are testing for. |
| 428 | Make updating the '1..42' string unnecessary. Or make sure that |
| 429 | you update it. |
| 430 | Test _all_ behaviors of a given operator, library, or function: |
| 431 | - All optional arguments |
| 432 | - Return values in various contexts (boolean, scalar, list, lvalue) |
| 433 | - Use both global and lexical variables |
| 434 | - Don't forget the exceptional, pathological cases. |
| 435 | |
| 436 | =back |
| 437 | |
| 438 | =head1 ACCEPTING A PATCH |
| 439 | |
| 440 | If you have received a patch file generated using the above section, |
| 441 | you should try out the patch. |
| 442 | |
| 443 | First we need to create a temporary new branch for these changes and |
| 444 | switch into it: |
| 445 | |
| 446 | % git checkout -b experimental |
| 447 | |
| 448 | Patches that were formatted by C<git format-patch> are applied with |
| 449 | C<git am>: |
| 450 | |
| 451 | % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
| 452 | Applying Rename Leon Brocard to Orange Brocard |
| 453 | |
| 454 | If just a raw diff is provided, it is also possible use this two-step |
| 455 | process: |
| 456 | |
| 457 | % git apply bugfix.diff |
| 458 | % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>" |
| 459 | |
| 460 | Now we can inspect the change: |
| 461 | |
| 462 | % git show HEAD |
| 463 | commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 |
| 464 | Author: Leon Brocard <acme@astray.com> |
| 465 | Date: Fri Dec 19 17:02:59 2008 +0000 |
| 466 | |
| 467 | Rename Leon Brocard to Orange Brocard |
| 468 | |
| 469 | diff --git a/AUTHORS b/AUTHORS |
| 470 | index 293dd70..722c93e 100644 |
| 471 | --- a/AUTHORS |
| 472 | +++ b/AUTHORS |
| 473 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
| 474 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
| 475 | Leif Huhn <leif@hale.dkstat.com> |
| 476 | Len Johnson <lenjay@ibm.net> |
| 477 | -Leon Brocard <acme@astray.com> |
| 478 | +Orange Brocard <acme@astray.com> |
| 479 | Les Peters <lpeters@aol.net> |
| 480 | Lesley Binks <lesley.binks@gmail.com> |
| 481 | Lincoln D. Stein <lstein@cshl.org> |
| 482 | |
| 483 | If you are a committer to Perl and you think the patch is good, you can |
| 484 | then merge it into blead then push it out to the main repository: |
| 485 | |
| 486 | % git checkout blead |
| 487 | % git merge experimental |
| 488 | % git push |
| 489 | |
| 490 | If you want to delete your temporary branch, you may do so with: |
| 491 | |
| 492 | % git checkout blead |
| 493 | % git branch -d experimental |
| 494 | error: The branch 'experimental' is not an ancestor of your current HEAD. |
| 495 | If you are sure you want to delete it, run 'git branch -D experimental'. |
| 496 | % git branch -D experimental |
| 497 | Deleted branch experimental. |
| 498 | |
| 499 | =head1 CLEANING A WORKING DIRECTORY |
| 500 | |
| 501 | The command C<git clean> can with varying arguments be used as a |
| 502 | replacement for C<make clean>. |
| 503 | |
| 504 | To reset your working directory to a pristine condition you can do: |
| 505 | |
| 506 | git clean -dxf |
| 507 | |
| 508 | However, be aware this will delete ALL untracked content. You can use |
| 509 | |
| 510 | git clean -Xf |
| 511 | |
| 512 | to remove all ignored untracked files, such as build and test |
| 513 | byproduct, but leave any manually created files alone. |
| 514 | |
| 515 | If you only want to cancel some uncommitted edits, you can use C<git |
| 516 | checkout> and give it a list of files to be reverted, or C<git checkout |
| 517 | -f> to revert them all. |
| 518 | |
| 519 | If you want to cancel one or several commits, you can use C<git reset>. |
| 520 | |
| 521 | =head1 BISECTING |
| 522 | |
| 523 | C<git> provides a built-in way to determine, with a binary search in |
| 524 | the history, which commit should be blamed for introducing a given bug. |
| 525 | |
| 526 | Suppose that we have a script F<~/testcase.pl> that exits with C<0> |
| 527 | when some behaviour is correct, and with C<1> when it's faulty. We need |
| 528 | an helper script that automates building C<perl> and running the |
| 529 | testcase: |
| 530 | |
| 531 | % cat ~/run |
| 532 | #!/bin/sh |
| 533 | git clean -dxf |
| 534 | # If you can use ccache, add -Dcc=ccache\ gcc -Dld=gcc to the Configure line |
| 535 | sh Configure -des -Dusedevel -Doptimize="-g" |
| 536 | test -f config.sh || exit 125 |
| 537 | # Correct makefile for newer GNU gcc |
| 538 | perl -ni -we 'print unless /<(?:built-in|command)/' makefile x2p/makefile |
| 539 | # if you just need miniperl, replace test_prep with miniperl |
| 540 | make -j4 test_prep |
| 541 | -x ./perl || exit 125 |
| 542 | ./perl -Ilib ~/testcase.pl |
| 543 | ret=$? |
| 544 | git clean -dxf |
| 545 | exit $ret |
| 546 | |
| 547 | This script may return C<125> to indicate that the corresponding commit |
| 548 | should be skipped. Otherwise, it returns the status of |
| 549 | F<~/testcase.pl>. |
| 550 | |
| 551 | We first enter in bisect mode with: |
| 552 | |
| 553 | % git bisect start |
| 554 | |
| 555 | For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, |
| 556 | C<git> will learn about this when you enter: |
| 557 | |
| 558 | % git bisect bad |
| 559 | % git bisect good perl-5.10.0 |
| 560 | Bisecting: 853 revisions left to test after this |
| 561 | |
| 562 | This results in checking out the median commit between C<HEAD> and |
| 563 | C<perl-5.10.0>. We can then run the bisecting process with: |
| 564 | |
| 565 | % git bisect run ~/run |
| 566 | |
| 567 | When the first bad commit is isolated, C<git bisect> will tell you so: |
| 568 | |
| 569 | ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit |
| 570 | commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 |
| 571 | Author: Dave Mitchell <davem@fdisolutions.com> |
| 572 | Date: Sat Feb 9 14:56:23 2008 +0000 |
| 573 | |
| 574 | [perl #49472] Attributes + Unknown Error |
| 575 | ... |
| 576 | |
| 577 | bisect run success |
| 578 | |
| 579 | You can peek into the bisecting process with C<git bisect log> and |
| 580 | C<git bisect visualize>. C<git bisect reset> will get you out of bisect |
| 581 | mode. |
| 582 | |
| 583 | Please note that the first C<good> state must be an ancestor of the |
| 584 | first C<bad> state. If you want to search for the commit that I<solved> |
| 585 | some bug, you have to negate your test case (i.e. exit with C<1> if OK |
| 586 | and C<0> if not) and still mark the lower bound as C<good> and the |
| 587 | upper as C<bad>. The "first bad commit" has then to be understood as |
| 588 | the "first commit where the bug is solved". |
| 589 | |
| 590 | C<git help bisect> has much more information on how you can tweak your |
| 591 | binary searches. |
| 592 | |
| 593 | =head1 SUBMITTING A PATCH VIA GITHUB |
| 594 | |
| 595 | GitHub is a website that makes it easy to fork and publish projects |
| 596 | with Git. First you should set up a GitHub account and log in. |
| 597 | |
| 598 | Perl's git repository is mirrored on GitHub at this page: |
| 599 | |
| 600 | http://github.com/github/perl/tree/blead |
| 601 | |
| 602 | Visit the page and click the "fork" button. This clones the Perl git |
| 603 | repository for you and provides you with "Your Clone URL" from which |
| 604 | you should clone: |
| 605 | |
| 606 | % git clone git@github.com:USERNAME/perl.git perl-github |
| 607 | |
| 608 | We shall make the same patch as above, creating a new branch: |
| 609 | |
| 610 | % cd perl-github |
| 611 | % git remote add upstream git://github.com/github/perl.git |
| 612 | % git pull upstream blead |
| 613 | % git checkout -b orange |
| 614 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS |
| 615 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
| 616 | % git push origin orange |
| 617 | |
| 618 | The orange branch has been pushed to GitHub, so you should now send an |
| 619 | email to perl5-porters@perl.org with a description of your changes and |
| 620 | the following information: |
| 621 | |
| 622 | http://github.com/USERNAME/perl/tree/orange |
| 623 | git@github.com:USERNAME/perl.git branch orange |
| 624 | |
| 625 | =head1 MERGING FROM A BRANCH VIA GITHUB |
| 626 | |
| 627 | If someone has provided a branch via GitHub and you are a committer, |
| 628 | you should use the following in your perl-ssh directory: |
| 629 | |
| 630 | % git remote add dandv git://github.com/dandv/perl.git |
| 631 | % git fetch |
| 632 | |
| 633 | Now you can see the differences between the branch and blead: |
| 634 | |
| 635 | % git diff dandv/blead |
| 636 | |
| 637 | And you can see the commits: |
| 638 | |
| 639 | % git log dandv/blead |
| 640 | |
| 641 | If you approve of a specific commit, you can cherry pick it: |
| 642 | |
| 643 | % git cherry-pick 3adac458cb1c1d41af47fc66e67b49c8dec2323f |
| 644 | |
| 645 | Or you could just merge the whole branch if you like it all: |
| 646 | |
| 647 | % git merge dandv/blead |
| 648 | |
| 649 | And then push back to the repository: |
| 650 | |
| 651 | % git push |
| 652 | |
| 653 | =head1 COMMITTING TO MAINTENANCE VERSIONS |
| 654 | |
| 655 | Maintenance versions should only be altered to add critical bug fixes. |
| 656 | |
| 657 | To commit to a maintenance version of perl, you need to create a local |
| 658 | tracking branch: |
| 659 | |
| 660 | % git checkout --track -b maint-5.005 origin/maint-5.005 |
| 661 | |
| 662 | This creates a local branch named C<maint-5.005>, which tracks the |
| 663 | remote branch C<origin/maint-5.005>. Then you can pull, commit, merge |
| 664 | and push as before. |
| 665 | |
| 666 | You can also cherry-pick commits from blead and another branch, by |
| 667 | using the C<git cherry-pick> command. It is recommended to use the |
| 668 | B<-x> option to C<git cherry-pick> in order to record the SHA1 of the |
| 669 | original commit in the new commit message. |
| 670 | |
| 671 | =head1 SEE ALSO |
| 672 | |
| 673 | The git documentation, accessible via C<git help command>. |
| 674 | |