From: Leon Brocard Date: Mon, 26 Jan 2009 13:55:57 +0000 (+0000) Subject: Run podtidy on pod/perlrepository.pod and document how to do so X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=0549aefb17661247c2fa5f5c1b2836aca63a153d;p=p5sagit%2Fp5-mst-13.2.git Run podtidy on pod/perlrepository.pod and document how to do so --- diff --git a/pod/perlrepository.pod b/pod/perlrepository.pod index ecd7978..5bf2f7c 100644 --- a/pod/perlrepository.pod +++ b/pod/perlrepository.pod @@ -1,3 +1,7 @@ +=for comment +Consistent formatting of this file is achieved with: + perl ./Porting/podtidy pod/perlrepository.pod + =head1 NAME perlrepository - Using the Perl source repository @@ -193,10 +197,10 @@ This shows that there were changes to this document staged for commit, and that there were further changes in the working directory not yet staged. It also shows that there was an untracked file in the working directory, and as you can see shows how to change all of this. It also -shows that there is one commit on the working branch C which -has not been pushed to the C remote yet. B: that this -output is also what you see as a template if you do not provide a -message to C. +shows that there is one commit on the working branch C which has +not been pushed to the C remote yet. B: that this output +is also what you see as a template if you do not provide a message to +C. Assuming we commit all the mentioned changes above: @@ -238,10 +242,10 @@ that you're on the I branch, and your repository is up to date: % git checkout blead % git pull -(It's preferable to patch against the latest blead version, since patches -are usually integrated from blead to the maintenance branches. This -does not apply, obviously, in the rare case where your patch is specific -to a maintaince release.) +(It's preferable to patch against the latest blead version, since +patches are usually integrated from blead to the maintenance branches. +This does not apply, obviously, in the rare case where your patch is +specific to a maintaince release.) Now that we have everything up to date, we need to create a temporary new branch for these changes and switch into it: @@ -313,21 +317,21 @@ If you want to delete your temporary branch, you may do so with: =head2 A note on derived files Be aware that many files in the distribution are derivative--avoid -patching them, because git won't see the changes to them, and the -build process will overwrite them. -Patch the originals instead. Most utilities (like perldoc) are in -this category, i.e. patch utils/perldoc.PL rather than utils/perldoc. -Similarly, don't create patches for files under $src_root/ext from -their copies found in $install_root/lib. If you are unsure about the -proper location of a file that may have gotten copied while building -the source distribution, consult the C. +patching them, because git won't see the changes to them, and the build +process will overwrite them. Patch the originals instead. Most +utilities (like perldoc) are in this category, i.e. patch +utils/perldoc.PL rather than utils/perldoc. Similarly, don't create +patches for files under $src_root/ext from their copies found in +$install_root/lib. If you are unsure about the proper location of a +file that may have gotten copied while building the source +distribution, consult the C. =head2 A note on binary files -Since the patch(1) utility cannot deal with binary files, it's important -that you either avoid the use of binary files in your patch, generate the -files dynamically, or that you encode any binary files using the -F utility. +Since the patch(1) utility cannot deal with binary files, it's +important that you either avoid the use of binary files in your patch, +generate the files dynamically, or that you encode any binary files +using the F utility. Assuming you needed to include a gzip-encoded file for a module's test suite, you might do this as follows using the F utility: @@ -336,17 +340,18 @@ suite, you might do this as follows using the F utility: Writing lib/Some/Module/t/src/t.gz into lib/Some/Module/t/src/t.gz.packed This will replace the C file with an encoded counterpart. During -C, before any tests are run, perl's Makefile will restore all -the C<.packed> files mentioned in the MANIFEST to their original name. -This means that the test suite does not need to be aware of this packing -scheme and will not need to be altered. +C, before any tests are run, perl's Makefile will restore +all the C<.packed> files mentioned in the MANIFEST to their original +name. This means that the test suite does not need to be aware of this +packing scheme and will not need to be altered. =head2 Getting your patch accepted -The first thing you should include with your patch is a description of the -problem that the patch corrects. If it is a code patch (rather than a -documentation patch) you should also include a small test case that -illustrates the bug (a patch to an existing test file is preferred). +The first thing you should include with your patch is a description of +the problem that the patch corrects. If it is a code patch (rather +than a documentation patch) you should also include a small test case +that illustrates the bug (a patch to an existing test file is +preferred). If you are submitting a code patch there are several other things that you need to do. @@ -355,18 +360,20 @@ you need to do. =item Comments, Comments, Comments -Be sure to adequately comment your code. While commenting every -line is unnecessary, anything that takes advantage of side effects of +Be sure to adequately comment your code. While commenting every line +is unnecessary, anything that takes advantage of side effects of operators, that creates changes that will be felt outside of the -function being patched, or that others may find confusing should -be documented. If you are going to err, it is better to err on the -side of adding too many comments than too few. +function being patched, or that others may find confusing should be +documented. If you are going to err, it is better to err on the side +of adding too many comments than too few. =item Style -In general, please follow the particular style of the code you are patching. +In general, please follow the particular style of the code you are +patching. -In particular, follow these general guidelines for patching Perl sources: +In particular, follow these general guidelines for patching Perl +sources: 8-wide tabs (no exceptions!) 4-wide indents for code, 2-wide indents for nested CPP #defines @@ -388,10 +395,10 @@ In particular, follow these general guidelines for patching Perl sources: =item Testsuite -When submitting a patch you should make every effort to also include -an addition to perl's regression tests to properly exercise your -patch. Your testsuite additions should generally follow these -guidelines (courtesy of Gurusamy Sarathy ): +When submitting a patch you should make every effort to also include an +addition to perl's regression tests to properly exercise your patch. +Your testsuite additions should generally follow these guidelines +(courtesy of Gurusamy Sarathy ): Know what you're testing. Read the docs, and the source. Tend to fail, not succeed. @@ -498,8 +505,8 @@ However, be aware this will delete ALL untracked content. You can use to remove all ignored untracked files, such as build and test byproduct, but leave any manually created files alone. -If you only want to cancel some uncommitted edits, you can use -C and give it a list of files to be reverted. +If you only want to cancel some uncommitted edits, you can use C and give it a list of files to be reverted. If you want to cancel one or several commits, you can use C. @@ -574,15 +581,16 @@ tracking branch: % git checkout --track -b maint-5.005 origin/maint-5.005 -This creates a local branch named C, which tracks the remote -branch C. Then you can pull, commit, merge and push as -before. +This creates a local branch named C, which tracks the +remote branch C. Then you can pull, commit, merge +and push as before. You can also cherry-pick commits from blead and another branch, by -using the C command. It is recommended to use the B<-x> -option to C in order to record the SHA1 of the original -commit in the new commit message. +using the C command. It is recommended to use the +B<-x> option to C in order to record the SHA1 of the +original commit in the new commit message. =head1 SEE ALSO The git documentation, accessible via C. +