argra****@users*****
argra****@users*****
2013年 4月 3日 (水) 03:50:57 JST
Index: docs/perl/5.10.1/perlrepository.pod diff -u /dev/null docs/perl/5.10.1/perlrepository.pod:1.1 --- /dev/null Wed Apr 3 03:50:56 2013 +++ docs/perl/5.10.1/perlrepository.pod Wed Apr 3 03:50:55 2013 @@ -0,0 +1,1529 @@ + +=encoding euc-jp + +=for comment +Consistent formatting of this file is achieved with: + perl ./Porting/podtidy pod/perlrepository.pod + +=head1 NAME + +=begin original + +perlrepository - Using the Perl source repository + +=end original + +perlrepository - Perl ソースリポジトリを使う + +=head1 SYNOPSIS + +=begin original + +All of Perl's source code is kept centrally in a Git repository at +I<perl5.git.perl.org>. The repository contains many Perl revisions from +Perl 1 onwards and all the revisions from Perforce, the version control +system we were using previously. This repository is accessible in +different ways. + +=end original + +All of Perl's source code is kept centrally in a Git repository at +I<perl5.git.perl.org>. The repository contains many Perl revisions from +Perl 1 onwards and all the revisions from Perforce, the version control +system we were using previously. This repository is accessible in +different ways. +(TBT) + +=begin original + +The full repository takes up about 80MB of disk space. A check out of +the blead branch (that is, the main development branch, which contains +bleadperl, the development version of perl 5) takes up about 160MB of +disk space (including the repository). A build of bleadperl takes up +about 200MB (including the repository and the check out). + +=end original + +The full repository takes up about 80MB of disk space. A check out of +the blead branch (that is, the main development branch, which contains +bleadperl, the development version of perl 5) takes up about 160MB of +disk space (including the repository). A build of bleadperl takes up +about 200MB (including the repository and the check out). +(TBT) + +=head1 GETTING ACCESS TO THE REPOSITORY + +=head2 READ ACCESS VIA THE WEB + +=begin original + +You may access the repository over the web. This allows you to browse +the tree, see recent commits, subscribe to RSS feeds for the changes, +search for particular commits and more. You may access it at: + +=end original + +You may access the repository over the web. This allows you to browse +the tree, see recent commits, subscribe to RSS feeds for the changes, +search for particular commits and more. You may access it at: +(TBT) + + http://perl5.git.perl.org/perl.git + +=begin original + +A mirror of the repository is found at: + +=end original + +リポジトリのミラーは以下にあります: + + http://github.com/github/perl + +=head2 READ ACCESS VIA GIT + +=begin original + +You will need a copy of Git for your computer. You can fetch a copy of +the repository using the Git protocol (which uses port 9418): + +=end original + +You will need a copy of Git for your computer. You can fetch a copy of +the repository using the Git protocol (which uses port 9418): +(TBT) + + git clone git://perl5.git.perl.org/perl.git perl-git + +=begin original + +This clones the repository and makes a local copy in the F<perl-git> +directory. + +=end original + +This clones the repository and makes a local copy in the F<perl-git> +directory. +(TBT) + +=begin original + +If your local network does not allow you to use port 9418, then you can +fetch a copy of the repository over HTTP (this is slower): + +=end original + +If your local network does not allow you to use port 9418, then you can +fetch a copy of the repository over HTTP (this is slower): +(TBT) + + git clone http://perl5.git.perl.org/perl.git perl-http + +=begin original + +This clones the repository and makes a local copy in the F<perl-http> +directory. + +=end original + +This clones the repository and makes a local copy in the F<perl-http> +directory. +(TBT) + +=head2 WRITE ACCESS TO THE REPOSITORY + +=begin original + +If you are a committer, then you can fetch a copy of the repository +that you can push back on with: + +=end original + +If you are a committer, then you can fetch a copy of the repository +that you can push back on with: +(TBT) + + git clone ssh://perl5.git.perl.org/gitroot/perl.git perl-ssh + +=begin original + +This clones the repository and makes a local copy in the F<perl-ssh> +directory. + +=end original + +This clones the repository and makes a local copy in the F<perl-ssh> +directory. +(TBT) + +=begin original + +If you cloned using the git protocol, which is faster than ssh, then +you will need to modify your config in order to enable pushing. Edit +F<.git/config> where you will see something like: + +=end original + +If you cloned using the git protocol, which is faster than ssh, then +you will need to modify your config in order to enable pushing. Edit +F<.git/config> where you will see something like: +(TBT) + + [remote "origin"] + url = git://perl5.git.perl.org/perl.git + +=begin original + +change that to something like this: + +=end original + +以下のようなものに変更します: + + [remote "origin"] + url = ssh://perl5.git.perl.org/gitroot/perl.git + +=begin original + +NOTE: there are symlinks set up so that the /gitroot is optional and +since SSH is the default protocol you can actually shorten the "url" to +C<perl5.git.perl.org:/perl.git>. + +=end original + +NOTE: there are symlinks set up so that the /gitroot is optional and +since SSH is the default protocol you can actually shorten the "url" to +C<perl5.git.perl.org:/perl.git>. +(TBT) + +=begin original + +You can also set up your user name and e-mail address. For example + +=end original + +ユーザー名と e-mail アドレスも設定できます。 +例えば + + % git config user.name "Leon Brocard" + % git config user.email acme****@astra***** + +=begin original + +It is also possible to keep C<origin> as a git remote, and add a new +remote for ssh access: + +=end original + +It is also possible to keep C<origin> as a git remote, and add a new +remote for ssh access: +(TBT) + + % git remote add camel perl5.git.perl.org:/perl.git + +=begin original + +This allows you to update your local repository by pulling from +C<origin>, which is faster and doesn't require you to authenticate, and +to push your changes back with the C<camel> remote: + +=end original + +This allows you to update your local repository by pulling from +C<origin>, which is faster and doesn't require you to authenticate, and +to push your changes back with the C<camel> remote: +(TBT) + + % git fetch camel + % git push camel + +=begin original + +The C<fetch> command just updates the C<camel> refs, as the objects +themselves should have been fetched when pulling from C<origin>. + +=end original + +The C<fetch> command just updates the C<camel> refs, as the objects +themselves should have been fetched when pulling from C<origin>. +(TBT) + +=begin original + +The committers have access to 2 servers that serve perl5.git.perl.org. +One is camel.booking.com, which is the 'master' repository. The +perl5.git.perl.org IP address also lives on this machine. The second +one is dromedary.booking.com, which can be used for general testing and +development. Dromedary syncs the git tree from camel every few minutes, +you should not push there. Both machines also have a full CPAN mirror. +To share files with the general public, dromedary serves your +~/public_html/ as http://users.perl5.git.perl.org/~yourlogin/ + +=end original + +The committers have access to 2 servers that serve perl5.git.perl.org. +One is camel.booking.com, which is the 'master' repository. The +perl5.git.perl.org IP address also lives on this machine. The second +one is dromedary.booking.com, which can be used for general testing and +development. Dromedary syncs the git tree from camel every few minutes, +you should not push there. Both machines also have a full CPAN mirror. +To share files with the general public, dromedary serves your +~/public_html/ as http://users.perl5.git.perl.org/~yourlogin/ +(TBT) + +=head1 OVERVIEW OF THE REPOSITORY + +=begin original + +Once you have changed into the repository directory, you can inspect +it. + +=end original + +Once you have changed into the repository directory, you can inspect +it. +(TBT) + +=begin original + +After a clone the repository will contain a single local branch, which +will be the current branch as well, as indicated by the asterisk. + +=end original + +After a clone the repository will contain a single local branch, which +will be the current branch as well, as indicated by the asterisk. +(TBT) + + % git branch + * blead + +=begin original + +Using the -a switch to C<branch> will also show the remote tracking +branches in the repository: + +=end original + +Using the -a switch to C<branch> will also show the remote tracking +branches in the repository: +(TBT) + + % git branch -a + * blead + origin/HEAD + origin/blead + ... + +=begin original + +The branches that begin with "origin" correspond to the "git remote" +that you cloned from (which is named "origin"). Each branch on the +remote will be exactly tracked by theses branches. You should NEVER do +work on these remote tracking branches. You only ever do work in a +local branch. Local branches can be configured to automerge (on pull) +from a designated remote tracking branch. This is the case with the +default branch C<blead> which will be configured to merge from the +remote tracking branch C<origin/blead>. + +=end original + +The branches that begin with "origin" correspond to the "git remote" +that you cloned from (which is named "origin"). Each branch on the +remote will be exactly tracked by theses branches. You should NEVER do +work on these remote tracking branches. You only ever do work in a +local branch. Local branches can be configured to automerge (on pull) +from a designated remote tracking branch. This is the case with the +default branch C<blead> which will be configured to merge from the +remote tracking branch C<origin/blead>. +(TBT) + +=begin original + +You can see recent commits: + +=end original + +最近のコミットを見られます: + + % git log + +=begin original + +And pull new changes from the repository, and update your local +repository (must be clean first) + +=end original + +And pull new changes from the repository, and update your local +repository (must be clean first) +(TBT) + + % git pull + +=begin original + +Assuming we are on the branch C<blead> immediately after a pull, this +command would be more or less equivalent to: + +=end original + +Assuming we are on the branch C<blead> immediately after a pull, this +command would be more or less equivalent to: +(TBT) + + % git fetch + % git merge origin/blead + +=begin original + +In fact if you want to update your local repository without touching +your working directory you do: + +=end original + +In fact if you want to update your local repository without touching +your working directory you do: +(TBT) + + % git fetch + +=begin original + +And if you want to update your remote-tracking branches for all defined +remotes simultaneously you can do + +=end original + +And if you want to update your remote-tracking branches for all defined +remotes simultaneously you can do +(TBT) + + % git remote update + +=begin original + +Neither of these last two commands will update your working directory, +however both will update the remote-tracking branches in your +repository. + +=end original + +Neither of these last two commands will update your working directory, +however both will update the remote-tracking branches in your +repository. +(TBT) + +=begin original + +To switch to another branch: + +=end original + +他のブランチに切り替えるには: + + % git checkout origin/maint-5.8-dor + +=begin original + +To make a local branch of a remote branch: + +=end original + +リモートブランチのローカルブランチを作るには: + + % git checkout -b maint-5.10 origin/maint-5.10 + +=begin original + +To switch back to blead: + +=end original + +blead に戻るには: + + % git checkout blead + +=head2 FINDING OUT YOUR STATUS + +=begin original + +The most common git command you will use will probably be + +=end original + +おそらくもっともよく使う git コマンドは: + + % git status + +=begin original + +This command will produce as output a description of the current state +of the repository, including modified files and unignored untracked +files, and in addition it will show things like what files have been +staged for the next commit, and usually some useful information about +how to change things. For instance the following: + +=end original + +This command will produce as output a description of the current state +of the repository, including modified files and unignored untracked +files, and in addition it will show things like what files have been +staged for the next commit, and usually some useful information about +how to change things. For instance the following: +(TBT) + + $ git status + # On branch blead + # Your branch is ahead of 'origin/blead' by 1 commit. + # + # Changes to be committed: + # (use "git reset HEAD <file>..." to unstage) + # + # modified: pod/perlrepository.pod + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # + # modified: pod/perlrepository.pod + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # deliberate.untracked + +=begin original + +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<blead> which has +not been pushed to the C<origin> remote yet. B<NOTE>: that this output +is also what you see as a template if you do not provide a message to +C<git commit>. + +=end original + +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<blead> which has +not been pushed to the C<origin> remote yet. B<NOTE>: that this output +is also what you see as a template if you do not provide a message to +C<git commit>. +(TBT) + +=begin original + +Assuming we commit all the mentioned changes above: + +=end original + +既に触れた全ての変更をコミットすると仮定すると: + + % git commit -a -m'explain git status and stuff about remotes' + Created commit daf8e63: explain git status and stuff about remotes + 1 files changed, 83 insertions(+), 3 deletions(-) + +=begin original + +We can re-run git status and see something like this: + +=end original + +git status を再実行して、以下のようなものが得られます: + + % git status + # On branch blead + # Your branch is ahead of 'origin/blead' by 2 commits. + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # deliberate.untracked + nothing added to commit but untracked files present (use "git add" to track) + +=begin original + +When in doubt, before you do anything else, check your status and read +it carefully, many questions are answered directly by the git status +output. + +=end original + +When in doubt, before you do anything else, check your status and read +it carefully, many questions are answered directly by the git status +output. +(TBT) + +=head1 SUBMITTING A PATCH + +=begin original + +If you have a patch in mind for Perl, you should first get a copy of +the repository: + +=end original + +If you have a patch in mind for Perl, you should first get a copy of +the repository: +(TBT) + + % git clone git://perl5.git.perl.org/perl.git perl-git + +=begin original + +Then change into the directory: + +=end original + +それからディレクトリを変更します: + + % cd perl-git + +=begin original + +Alternatively, if you already have a Perl repository, you should ensure +that you're on the I<blead> branch, and your repository is up to date: + +=end original + +Alternatively, if you already have a Perl repository, you should ensure +that you're on the I<blead> branch, and your repository is up to date: +(TBT) + + % git checkout blead + % git pull + +=begin original + +It's preferable to patch against the latest blead version, since this +is where new development occurs for all changes other than critical bug +fixes. Critical bug fix patches should be made against the relevant +maint branches, or should be submitted with a note indicating all the +branches where the fix should be applied. + +=end original + +It's preferable to patch against the latest blead version, since this +is where new development occurs for all changes other than critical bug +fixes. Critical bug fix patches should be made against the relevant +maint branches, or should be submitted with a note indicating all the +branches where the fix should be applied. +(TBT) + +=begin original + +Now that we have everything up to date, we need to create a temporary +new branch for these changes and switch into it: + +=end original + +Now that we have everything up to date, we need to create a temporary +new branch for these changes and switch into it: +(TBT) + + % git checkout -b orange + +=begin original + +which is the short form of + +=end original + +これは以下のものの短縮形です + + % git branch orange + % git checkout orange + +=begin original + +Then make your changes. For example, if Leon Brocard changes his name +to Orange Brocard, we should change his name in the AUTHORS file: + +=end original + +Then make your changes. For example, if Leon Brocard changes his name +to Orange Brocard, we should change his name in the AUTHORS file: +(TBT) + + % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS + +=begin original + +You can see what files are changed: + +=end original + +どのファイルを変更したかを見られます: + + % git status + # On branch orange + # Changes to be committed: + # (use "git reset HEAD <file>..." to unstage) + # + # modified: AUTHORS + # + +=begin original + +And you can see the changes: + +=end original + +そして変更が見られます: + + % git diff + diff --git a/AUTHORS b/AUTHORS + index 293dd70..722c93e 100644 + --- a/AUTHORS + +++ b/AUTHORS + @@ -541,7 +541,7 @@ Lars Hecking <lheck****@nmrc*****> + Laszlo Molnar <laszl****@eth*****> + Leif Huhn <leif****@hale*****> + Len Johnson <lenja****@ibm*****> + -Leon Brocard <acme****@astra*****> + +Orange Brocard <acme****@astra*****> + Les Peters <lpete****@aol*****> + Lesley Binks <lesle****@gmail*****> + Lincoln D. Stein <lstei****@cshl*****> + +=begin original + +Now commit your change locally: + +=end original + +ここで変更をローカルにコミットします: + + % git commit -a -m 'Rename Leon Brocard to Orange Brocard' + Created commit 6196c1d: Rename Leon Brocard to Orange Brocard + 1 files changed, 1 insertions(+), 1 deletions(-) + +=begin original + +You can examine your last commit with: + +=end original + +最後のコミットを以下のようにして検査できます: + + % git show HEAD + +=begin original + +and if you are not happy with either the description or the patch +itself you can fix it up by editing the files once more and then issue: + +=end original + +and if you are not happy with either the description or the patch +itself you can fix it up by editing the files once more and then issue: +(TBT) + + % git commit -a --amend + +=begin original + +Now you should create a patch file for all your local changes: + +=end original + +ここで全てのローカルな変更のためのパッチファイルを作るべきです: + + % git format-patch origin + 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch + +=begin original + +You should now send an email to perl5****@perl***** with a +description of your changes, and include this patch file as an +attachment. + +=end original + +You should now send an email to perl5****@perl***** with a +description of your changes, and include this patch file as an +attachment. +(TBT) + +=begin original + +If you want to delete your temporary branch, you may do so with: + +=end original + +一時的なブランチを削除したいなら、以下のようにできます: + + % git checkout blead + % git branch -d orange + error: The branch 'orange' is not an ancestor of your current HEAD. + If you are sure you want to delete it, run 'git branch -D orange'. + % git branch -D orange + Deleted branch orange. + +=head2 A note on derived files + +=begin original + +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<MANIFEST>. + +=end original + +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<MANIFEST>. +(TBT) + +=head2 A note on binary files + +=begin original + +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<uupacktool.pl> utility. + +=end original + +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<uupacktool.pl> utility. +(TBT) + +=begin original + +Assuming you needed to include a gzip-encoded file for a module's test +suite, you might do this as follows using the F<uupacktool.pl> utility: + +=end original + +Assuming you needed to include a gzip-encoded file for a module's test +suite, you might do this as follows using the F<uupacktool.pl> utility: +(TBT) + + $ perl uupacktool.pl -v -p -D lib/Some/Module/t/src/t.gz + Writing lib/Some/Module/t/src/t.gz into lib/Some/Module/t/src/t.gz.packed + +=begin original + +This will replace the C<t.gz> file with an encoded counterpart. During +C<make test>, 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. + +=end original + +This will replace the C<t.gz> file with an encoded counterpart. During +C<make test>, 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. +(TBT) + +=head2 Getting your patch accepted + +=begin original + +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). + +=end original + +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). +(TBT) + +=begin original + +If you are submitting a code patch there are several other things that +you need to do. + +=end original + +If you are submitting a code patch there are several other things that +you need to do. +(TBT) + +=over 4 + +=item Comments, Comments, Comments + +=begin original + +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. + +=end original + +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. +(TBT) + +=item Style + +=begin original + +In general, please follow the particular style of the code you are +patching. + +=end original + +In general, please follow the particular style of the code you are +patching. +(TBT) + +=begin original + +In particular, follow these general guidelines for patching Perl +sources: + +=end original + +In particular, follow these general guidelines for patching Perl +sources: +(TBT) + + 8-wide tabs (no exceptions!) + 4-wide indents for code, 2-wide indents for nested CPP #defines + try hard not to exceed 79-columns + ANSI C prototypes + uncuddled elses and "K&R" style for indenting control constructs + no C++ style (//) comments + mark places that need to be revisited with XXX (and revisit often!) + opening brace lines up with "if" when conditional spans multiple + lines; should be at end-of-line otherwise + in function definitions, name starts in column 0 (return value is on + previous line) + single space after keywords that are followed by parens, no space + between function name and following paren + avoid assignments in conditionals, but if they're unavoidable, use + extra paren, e.g. "if (a && (b = c)) ..." + "return foo;" rather than "return(foo);" + "if (!foo) ..." rather than "if (foo == FALSE) ..." etc. + +=item Testsuite + +=begin original + +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 <gsar****@activ*****>): + +=end original + +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 <gsar****@activ*****>): +(TBT) + + Know what you're testing. Read the docs, and the source. + Tend to fail, not succeed. + Interpret results strictly. + Use unrelated features (this will flush out bizarre interactions). + Use non-standard idioms (otherwise you are not testing TIMTOWTDI). + Avoid using hardcoded test numbers whenever possible (the + EXPECTED/GOT found in t/op/tie.t is much more maintainable, + and gives better failure reports). + Give meaningful error messages when a test fails. + Avoid using qx// and system() unless you are testing for them. If you + do use them, make sure that you cover _all_ perl platforms. + Unlink any temporary files you create. + Promote unforeseen warnings to errors with $SIG{__WARN__}. + Be sure to use the libraries and modules shipped with the version + being tested, not those that were already installed. + Add comments to the code explaining what you are testing for. + Make updating the '1..42' string unnecessary. Or make sure that + you update it. + Test _all_ behaviors of a given operator, library, or function: + - All optional arguments + - Return values in various contexts (boolean, scalar, list, lvalue) + - Use both global and lexical variables + - Don't forget the exceptional, pathological cases. + +=back + +=head1 ACCEPTING A PATCH + +=begin original + +If you have received a patch file generated using the above section, +you should try out the patch. + +=end original + +If you have received a patch file generated using the above section, +you should try out the patch. +(TBT) + +=begin original + +First we need to create a temporary new branch for these changes and +switch into it: + +=end original + +First we need to create a temporary new branch for these changes and +switch into it: +(TBT) + + % git checkout -b experimental + +=begin original + +Patches that were formatted by C<git format-patch> are applied with +C<git am>: + +=end original + +Patches that were formatted by C<git format-patch> are applied with +C<git am>: +(TBT) + + % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch + Applying Rename Leon Brocard to Orange Brocard + +=begin original + +If just a raw diff is provided, it is also possible use this two-step +process: + +=end original + +If just a raw diff is provided, it is also possible use this two-step +process: +(TBT) + + % git apply bugfix.diff + % git commit -a -m "Some fixing" --author="That Guy <that.****@inter*****>" + +=begin original + +Now we can inspect the change: + +=end original + +ここで変更を検査できます: + + % git show HEAD + commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 + Author: Leon Brocard <acme****@astra*****> + Date: Fri Dec 19 17:02:59 2008 +0000 + + Rename Leon Brocard to Orange Brocard + + diff --git a/AUTHORS b/AUTHORS + index 293dd70..722c93e 100644 + --- a/AUTHORS + +++ b/AUTHORS + @@ -541,7 +541,7 @@ Lars Hecking <lheck****@nmrc*****> + Laszlo Molnar <laszl****@eth*****> + Leif Huhn <leif****@hale*****> + Len Johnson <lenja****@ibm*****> + -Leon Brocard <acme****@astra*****> + +Orange Brocard <acme****@astra*****> + Les Peters <lpete****@aol*****> + Lesley Binks <lesle****@gmail*****> + Lincoln D. Stein <lstei****@cshl*****> + +=begin original + +If you are a committer to Perl and you think the patch is good, you can +then merge it into blead then push it out to the main repository: + +=end original + +If you are a committer to Perl and you think the patch is good, you can +then merge it into blead then push it out to the main repository: +(TBT) + + % git checkout blead + % git merge experimental + % git push + +=begin original + +If you want to delete your temporary branch, you may do so with: + +=end original + +一時的なブランチを削除したいなら、以下のようにできます: + + % git checkout blead + % git branch -d experimental + error: The branch 'experimental' is not an ancestor of your current HEAD. + If you are sure you want to delete it, run 'git branch -D experimental'. + % git branch -D experimental + Deleted branch experimental. + +=head1 CLEANING A WORKING DIRECTORY + +=begin original + +The command C<git clean> can with varying arguments be used as a +replacement for C<make clean>. + +=end original + +The command C<git clean> can with varying arguments be used as a +replacement for C<make clean>. +(TBT) + +=begin original + +To reset your working directory to a pristine condition you can do: + +=end original + +To reset your working directory to a pristine condition you can do: +(TBT) + + git clean -dxf + +=begin original + +However, be aware this will delete ALL untracked content. You can use + +=end original + +However, be aware this will delete ALL untracked content. You can use +(TBT) + + git clean -Xf + +=begin original + +to remove all ignored untracked files, such as build and test +byproduct, but leave any manually created files alone. + +=end original + +to remove all ignored untracked files, such as build and test +byproduct, but leave any manually created files alone. +(TBT) + +=begin original + +If you only want to cancel some uncommitted edits, you can use C<git +checkout> and give it a list of files to be reverted, or C<git checkout +-f> to revert them all. + +=end original + +If you only want to cancel some uncommitted edits, you can use C<git +checkout> and give it a list of files to be reverted, or C<git checkout +-f> to revert them all. +(TBT) + +=begin original + +If you want to cancel one or several commits, you can use C<git reset>. + +=end original + +If you want to cancel one or several commits, you can use C<git reset>. +(TBT) + +=head1 BISECTING + +=begin original + +C<git> provides a built-in way to determine, with a binary search in +the history, which commit should be blamed for introducing a given bug. + +=end original + +C<git> provides a built-in way to determine, with a binary search in +the history, which commit should be blamed for introducing a given bug. +(TBT) + +=begin original + +Suppose that we have a script F<~/testcase.pl> that exits with C<0> +when some behaviour is correct, and with C<1> when it's faulty. We need +an helper script that automates building C<perl> and running the +testcase: + +=end original + +Suppose that we have a script F<~/testcase.pl> that exits with C<0> +when some behaviour is correct, and with C<1> when it's faulty. We need +an helper script that automates building C<perl> and running the +testcase: +(TBT) + + % cat ~/run + #!/bin/sh + git clean -dxf + # If you can use ccache, add -Dcc=ccache\ gcc -Dld=gcc to the Configure line + sh Configure -des -Dusedevel -Doptimize="-g" + test -f config.sh || exit 125 + # Correct makefile for newer GNU gcc + perl -ni -we 'print unless /<(?:built-in|command)/' makefile x2p/makefile + # if you just need miniperl, replace test_prep with miniperl + make -j4 test_prep + -x ./perl || exit 125 + ./perl -Ilib ~/testcase.pl + ret=$? + git clean -dxf + exit $ret + +=begin original + +This script may return C<125> to indicate that the corresponding commit +should be skipped. Otherwise, it returns the status of +F<~/testcase.pl>. + +=end original + +This script may return C<125> to indicate that the corresponding commit +should be skipped. Otherwise, it returns the status of +F<~/testcase.pl>. +(TBT) + +=begin original + +We first enter in bisect mode with: + +=end original + +まず bisect モードに入ります: + + % git bisect start + +=begin original + +For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, +C<git> will learn about this when you enter: + +=end original + +For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, +C<git> will learn about this when you enter: +(TBT) + + % git bisect bad + % git bisect good perl-5.10.0 + Bisecting: 853 revisions left to test after this + +=begin original + +This results in checking out the median commit between C<HEAD> and +C<perl-5.10.0>. We can then run the bisecting process with: + +=end original + +This results in checking out the median commit between C<HEAD> and +C<perl-5.10.0>. We can then run the bisecting process with: +(TBT) + + % git bisect run ~/run + +=begin original + +When the first bad commit is isolated, C<git bisect> will tell you so: + +=end original + +When the first bad commit is isolated, C<git bisect> will tell you so: +(TBT) + + ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit + commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 + Author: Dave Mitchell <davem****@fdiso*****> + Date: Sat Feb 9 14:56:23 2008 +0000 + + [perl #49472] Attributes + Unknown Error + ... + + bisect run success + +=begin original + +You can peek into the bisecting process with C<git bisect log> and +C<git bisect visualize>. C<git bisect reset> will get you out of bisect +mode. + +=end original + +You can peek into the bisecting process with C<git bisect log> and +C<git bisect visualize>. C<git bisect reset> will get you out of bisect +mode. +(TBT) + +=begin original + +Please note that the first C<good> state must be an ancestor of the +first C<bad> state. If you want to search for the commit that I<solved> +some bug, you have to negate your test case (i.e. exit with C<1> if OK +and C<0> if not) and still mark the lower bound as C<good> and the +upper as C<bad>. The "first bad commit" has then to be understood as +the "first commit where the bug is solved". + +=end original + +Please note that the first C<good> state must be an ancestor of the +first C<bad> state. If you want to search for the commit that I<solved> +some bug, you have to negate your test case (i.e. exit with C<1> if OK +and C<0> if not) and still mark the lower bound as C<good> and the +upper as C<bad>. The "first bad commit" has then to be understood as +the "first commit where the bug is solved". +(TBT) + +=begin original + +C<git help bisect> has much more information on how you can tweak your +binary searches. + +=end original + +C<git help bisect> has much more information on how you can tweak your +binary searches. +(TBT) + +=head1 SUBMITTING A PATCH VIA GITHUB + +=begin original + +GitHub is a website that makes it easy to fork and publish projects +with Git. First you should set up a GitHub account and log in. + +=end original + +GitHub is a website that makes it easy to fork and publish projects +with Git. First you should set up a GitHub account and log in. +(TBT) + +=begin original + +Perl's git repository is mirrored on GitHub at this page: + +=end original + +Perl's git repository is mirrored on GitHub at this page: +(TBT) + + http://github.com/github/perl/tree/blead + +=begin original + +Visit the page and click the "fork" button. This clones the Perl git +repository for you and provides you with "Your Clone URL" from which +you should clone: + +=end original + +Visit the page and click the "fork" button. This clones the Perl git +repository for you and provides you with "Your Clone URL" from which +you should clone: +(TBT) + + % git clone git****@githu*****:USERNAME/perl.git perl-github + +=begin original + +We shall make the same patch as above, creating a new branch: + +=end original + +We shall make the same patch as above, creating a new branch: +(TBT) + + % cd perl-github + % git remote add upstream git://github.com/github/perl.git + % git pull upstream blead + % git checkout -b orange + % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS + % git commit -a -m 'Rename Leon Brocard to Orange Brocard' + % git push origin orange + +=begin original + +The orange branch has been pushed to GitHub, so you should now send an +email to perl5****@perl***** with a description of your changes and +the following information: + +=end original + +The orange branch has been pushed to GitHub, so you should now send an +email to perl5****@perl***** with a description of your changes and +the following information: +(TBT) + + http://github.com/USERNAME/perl/tree/orange + git****@githu*****:USERNAME/perl.git branch orange + +=head1 MERGING FROM A BRANCH VIA GITHUB + +=begin original + +If someone has provided a branch via GitHub and you are a committer, +you should use the following in your perl-ssh directory: + +=end original + +If someone has provided a branch via GitHub and you are a committer, +you should use the following in your perl-ssh directory: +(TBT) + + % git remote add dandv git://github.com/dandv/perl.git + % git fetch + +=begin original + +Now you can see the differences between the branch and blead: + +=end original + +Now you can see the differences between the branch and blead: +(TBT) + + % git diff dandv/blead + +=begin original + +And you can see the commits: + +=end original + +And you can see the commits: +(TBT) + + % git log dandv/blead + +=begin original + +If you approve of a specific commit, you can cherry pick it: + +=end original + +If you approve of a specific commit, you can cherry pick it: +(TBT) + + % git cherry-pick 3adac458cb1c1d41af47fc66e67b49c8dec2323f + +=begin original + +Or you could just merge the whole branch if you like it all: + +=end original + +Or you could just merge the whole branch if you like it all: +(TBT) + + % git merge dandv/blead + +=begin original + +And then push back to the repository: + +=end original + +And then push back to the repository: +(TBT) + + % git push + +=head1 COMMITTING TO MAINTENANCE VERSIONS + +=begin original + +Maintenance versions should only be altered to add critical bug fixes. + +=end original + +Maintenance versions should only be altered to add critical bug fixes. +(TBT) + +=begin original + +To commit to a maintenance version of perl, you need to create a local +tracking branch: + +=end original + +To commit to a maintenance version of perl, you need to create a local +tracking branch: +(TBT) + + % git checkout --track -b maint-5.005 origin/maint-5.005 + +=begin original + +This creates a local branch named C<maint-5.005>, which tracks the +remote branch C<origin/maint-5.005>. Then you can pull, commit, merge +and push as before. + +=end original + +This creates a local branch named C<maint-5.005>, which tracks the +remote branch C<origin/maint-5.005>. Then you can pull, commit, merge +and push as before. +(TBT) + +=begin original + +You can also cherry-pick commits from blead and another branch, by +using the C<git cherry-pick> command. It is recommended to use the +B<-x> option to C<git cherry-pick> in order to record the SHA1 of the +original commit in the new commit message. + +=end original + +You can also cherry-pick commits from blead and another branch, by +using the C<git cherry-pick> command. It is recommended to use the +B<-x> option to C<git cherry-pick> in order to record the SHA1 of the +original commit in the new commit message. +(TBT) + +=head1 SEE ALSO + +=begin original + +The git documentation, accessible via C<git help command>. + +=end original + +C<git help command> でアクセスできる git 文書。 + +=begin meta + +Translate: SHIRAKATA Kentaro <argra****@ub32*****> +Status: in progress + +=end meta +
