pod/perlrepository.pod

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