diff options
Diffstat (limited to 'Master/tlpkg/tlperl/lib/pods/perlgit.pod')
-rw-r--r-- | Master/tlpkg/tlperl/lib/pods/perlgit.pod | 858 |
1 files changed, 858 insertions, 0 deletions
diff --git a/Master/tlpkg/tlperl/lib/pods/perlgit.pod b/Master/tlpkg/tlperl/lib/pods/perlgit.pod new file mode 100644 index 00000000000..eac7bb84b5e --- /dev/null +++ b/Master/tlpkg/tlperl/lib/pods/perlgit.pod @@ -0,0 +1,858 @@ +=encoding utf8 + +=for comment +Consistent formatting of this file is achieved with: + perl ./Porting/podtidy pod/perlgit.pod + +=head1 NAME + +perlgit - Detailed information about git and the Perl repository + +=head1 DESCRIPTION + +This document provides details on using git to develop Perl. If you are +just interested in working on a quick patch, see L<perlhack> first. +This document is intended for people who are regular contributors to +Perl, including those with write access to the git repository. + +=head1 CLONING THE REPOSITORY + +All of Perl's source code is kept centrally in a Git repository at +I<perl5.git.perl.org>. + +You can make a read-only clone of the repository by running: + + % git clone git://perl5.git.perl.org/perl.git perl + +This uses the git protocol (port 9418). + +If you cannot use the git protocol for firewall reasons, you can also +clone via http, though this is much slower: + + % git clone http://perl5.git.perl.org/perl.git perl + +=head1 WORKING WITH THE REPOSITORY + +Once you have changed into the repository directory, you can inspect +it. After a clone the repository will contain a single local branch, +which will be the current branch as well, as indicated by the asterisk. + + % git branch + * blead + +Using the -a switch to C<branch> will also show the remote tracking +branches in the repository: + + % git branch -a + * blead + origin/HEAD + origin/blead + ... + +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>. + +You can see recent commits: + + % git log + +And pull new changes from the repository, and update your local +repository (must be clean first) + + % git pull + +Assuming we are on the branch C<blead> immediately after a pull, this +command would be more or less equivalent to: + + % git fetch + % git merge origin/blead + +In fact if you want to update your local repository without touching +your working directory you do: + + % git fetch + +And if you want to update your remote-tracking branches for all defined +remotes simultaneously you can do + + % git remote update + +Neither of these last two commands will update your working directory, +however both will update the remote-tracking branches in your +repository. + +To make a local branch of a remote branch: + + % git checkout -b maint-5.10 origin/maint-5.10 + +To switch back to blead: + + % git checkout blead + +=head2 Finding out your status + +The most common git command you will use will probably be + + % git status + +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: + + $ 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/perlgit.pod + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # + # modified: pod/perlgit.pod + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # deliberate.untracked + +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>. + +=head2 Patch workflow + +First, please read L<perlhack> for details on hacking the Perl core. +That document covers many details on how to create a good patch. + +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: + + % git checkout blead + % git pull + +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. + +Now that we have everything up to date, we need to create a temporary +new branch for these changes and switch into it: + + % git checkout -b orange + +which is the short form of + + % git branch orange + % git checkout orange + +Creating a topic branch makes it easier for the maintainers to rebase +or merge back into the master blead for a more linear history. If you +don't work on a topic branch the maintainer has to manually cherry pick +your changes onto blead before they can be applied. + +That'll get you scolded on perl5-porters, so don't do that. Be Awesome. + +Then make your changes. For example, if Leon Brocard changes his name +to Orange Brocard, we should change his name in the AUTHORS file: + + % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS + +You can see what files are changed: + + % git status + # On branch orange + # Changes to be committed: + # (use "git reset HEAD <file>..." to unstage) + # + # modified: AUTHORS + # + +And you can see the changes: + + % git diff + diff --git a/AUTHORS b/AUTHORS + index 293dd70..722c93e 100644 + --- a/AUTHORS + +++ b/AUTHORS + @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> + Laszlo Molnar <laszlo.molnar@eth.ericsson.se> + Leif Huhn <leif@hale.dkstat.com> + Len Johnson <lenjay@ibm.net> + -Leon Brocard <acme@astray.com> + +Orange Brocard <acme@astray.com> + Les Peters <lpeters@aol.net> + Lesley Binks <lesley.binks@gmail.com> + Lincoln D. Stein <lstein@cshl.org> + +Now commit your change locally: + + % 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(-) + +The C<-a> option is used to include all files that git tracks that you +have changed. If at this time, you only want to commit some of the +files you have worked on, you can omit the C<-a> and use the command +C<S<git add I<FILE ...>>> before doing the commit. C<S<git add +--interactive>> allows you to even just commit portions of files +instead of all the changes in them. + +The C<-m> option is used to specify the commit message. If you omit it, +git will open a text editor for you to compose the message +interactively. This is useful when the changes are more complex than +the sample given here, and, depending on the editor, to know that the +first line of the commit message doesn't exceed the 50 character legal +maximum. + +Once you've finished writing your commit message and exited your +editor, git will write your change to disk and tell you something like +this: + + Created commit daf8e63: explain git status and stuff about remotes + 1 files changed, 83 insertions(+), 3 deletions(-) + +If you re-run C<git status>, you should see something like this: + + % 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) + +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. + +You can examine your last commit with: + + % git show HEAD + +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: + + % git commit -a --amend + +Now you should create a patch file for all your local changes: + + % git format-patch -M origin.. + 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch + +You should now send an email to to +L<perlbug@perl.org|mailto:perlbug@perl.org> with a description of your +changes, and include this patch file as an attachment. In addition to +being tracked by RT, mail to perlbug will automatically be forwarded to +perl5-porters (with manual moderation, so please be patient). You +should only send patches to +L<perl5-porters@perl.org|mailto:perl5-porters@perl.org> directly if the +patch is not ready to be applied, but intended for discussion. + +See the next section for how to configure and use git to send these +emails for you. + +If you want to delete your temporary branch, you may do so with: + + % 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 Committing your changes + +Assuming that you'd like to commit all the changes you've made as a +single atomic unit, run this command: + + % git commit -a + +(That C<-a> tells git to add every file you've changed to this commit. +New files aren't automatically added to your commit when you use +C<commit -a> If you want to add files or to commit some, but not all of +your changes, have a look at the documentation for C<git add>.) + +Git will start up your favorite text editor, so that you can craft a +commit message for your change. See L<perlhack/Commit message> for more +information about what makes a good commit message. + +Once you've finished writing your commit message and exited your +editor, git will write your change to disk and tell you something like +this: + + Created commit daf8e63: explain git status and stuff about remotes + 1 files changed, 83 insertions(+), 3 deletions(-) + +If you re-run C<git status>, you should see something like this: + + % 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) + +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. + +=head2 Using git to send patch emails + +Please read L<perlhack> first in order to figure out where your patches +should be sent. + +In your ~/git/perl repository, set the destination email to perl's bug +tracker: + + $ git config sendemail.to perlbug@perl.org + +Or maybe perl5-porters: + + $ git config sendemail.to perl5-porters@perl.org + +Then you can use git directly to send your patch emails: + + $ git send-email 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch + +You may need to set some configuration variables for your particular +email service provider. For example, to set your global git config to +send email via a gmail account: + + $ git config --global sendemail.smtpserver smtp.gmail.com + $ git config --global sendemail.smtpssl 1 + $ git config --global sendemail.smtpuser YOURUSERNAME@gmail.com + +With this configuration, you will be prompted for your gmail password +when you run 'git send-email'. You can also configure +C<sendemail.smtppass> with your password if you don't care about having +your password in the .gitconfig file. + +=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 +F<utils/perldoc.PL> rather than F<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>. + +=head2 Cleaning a working directory + +The command C<git clean> can with varying arguments be used as a +replacement for C<make clean>. + +To reset your working directory to a pristine condition you can do: + + % git clean -dxf + +However, be aware this will delete ALL untracked content. You can use + + % git clean -Xf + +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<git +checkout> and give it a list of files to be reverted, or C<git checkout +-f> to revert them all. + +If you want to cancel one or several commits, you can use C<git reset>. + +=head2 Bisecting + +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. + +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. You +need an helper script that automates building C<perl> and running the +testcase: + + % cat ~/run + #!/bin/sh + git clean -dxf + + # If you get './makedepend: 1: Syntax error: Unterminated quoted + # string' when bisecting versions of perl older than 5.9.5 this hack + # will work around the bug in makedepend.SH which was fixed in + # version 96a8704c. Make sure to comment out `git checkout makedepend.SH' + # below too. + git show blead:makedepend.SH > makedepend.SH + + # If you can use ccache, add -Dcc=ccache\ gcc -Dld=gcc to the Configure line + # if Encode is not needed for the test, you can speed up the bisect by + # excluding it from the runs with -Dnoextensions=Encode + 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 test_prep + [ -x ./perl ] || exit 125 + ./perl -Ilib ~/testcase.pl + ret=$? + [ $ret -gt 127 ] && ret=127 + # git checkout makedepend.SH + git clean -dxf + exit $ret + +This script may return C<125> to indicate that the corresponding commit +should be skipped. Otherwise, it returns the status of +F<~/testcase.pl>. + +You first enter in bisect mode with: + + % git bisect start + +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: + + % git bisect bad + % git bisect good perl-5.10.0 + Bisecting: 853 revisions left to test after this + +This results in checking out the median commit between C<HEAD> and +C<perl-5.10.0>. You can then run the bisecting process with: + + % git bisect run ~/run + +When the first bad commit is isolated, C<git bisect> will tell you so: + + ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit + commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 + Author: Dave Mitchell <davem@fdisolutions.com> + Date: Sat Feb 9 14:56:23 2008 +0000 + + [perl #49472] Attributes + Unknown Error + ... + + bisect run success + +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. + +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". + +C<git help bisect> has much more information on how you can tweak your +binary searches. +=head1 Topic branches and rewriting history + +Individual committers should create topic branches under +B<yourname>/B<some_descriptive_name>. Other committers should check +with a topic branch's creator before making any change to it. + +The simplest way to create a remote topic branch that works on all +versions of git is to push the current head as a new branch on the +remote, then check it out locally: + + $ branch="$yourname/$some_descriptive_name" + $ git push origin HEAD:$branch + $ git checkout -b $branch origin/$branch + +Users of git 1.7 or newer can do it in a more obvious manner: + + $ branch="$yourname/$some_descriptive_name" + $ git checkout -b $branch + $ git push origin -u $branch + +If you are not the creator of B<yourname>/B<some_descriptive_name>, you +might sometimes find that the original author has edited the branch's +history. There are lots of good reasons for this. Sometimes, an author +might simply be rebasing the branch onto a newer source point. +Sometimes, an author might have found an error in an early commit which +they wanted to fix before merging the branch to blead. + +Currently the master repository is configured to forbid +non-fast-forward merges. This means that the branches within can not be +rebased and pushed as a single step. + +The only way you will ever be allowed to rebase or modify the history +of a pushed branch is to delete it and push it as a new branch under +the same name. Please think carefully about doing this. It may be +better to sequentially rename your branches so that it is easier for +others working with you to cherry-pick their local changes onto the new +version. (XXX: needs explanation). + +If you want to rebase a personal topic branch, you will have to delete +your existing topic branch and push as a new version of it. You can do +this via the following formula (see the explanation about C<refspec>'s +in the git push documentation for details) after you have rebased your +branch: + + # first rebase + $ git checkout $user/$topic + $ git fetch + $ git rebase origin/blead + + # then "delete-and-push" + $ git push origin :$user/$topic + $ git push origin $user/$topic + +B<NOTE:> it is forbidden at the repository level to delete any of the +"primary" branches. That is any branch matching +C<m!^(blead|maint|perl)!>. Any attempt to do so will result in git +producing an error like this: + + $ git push origin :blead + *** It is forbidden to delete blead/maint branches in this repository + error: hooks/update exited with error code 1 + error: hook declined to update refs/heads/blead + To ssh://perl5.git.perl.org/perl + ! [remote rejected] blead (hook declined) + error: failed to push some refs to 'ssh://perl5.git.perl.org/perl' + +As a matter of policy we do B<not> edit the history of the blead and +maint-* branches. If a typo (or worse) sneaks into a commit to blead or +maint-*, we'll fix it in another commit. The only types of updates +allowed on these branches are "fast-forward's", where all history is +preserved. + +Annotated tags in the canonical perl.git repository will never be +deleted or modified. Think long and hard about whether you want to push +a local tag to perl.git before doing so. (Pushing unannotated tags is +not allowed.) + +=head3 Grafts + +The perl history contains one mistake which was not caught in the +conversion: a merge was recorded in the history between blead and +maint-5.10 where no merge actually occurred. Due to the nature of git, +this is now impossible to fix in the public repository. You can remove +this mis-merge locally by adding the following line to your +C<.git/info/grafts> file: + + 296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930 + +It is particularly important to have this graft line if any bisecting +is done in the area of the "merge" in question. + +=head2 Topic branches and rewriting history + +Individual committers should create topic branches under +B<yourname>/B<some_descriptive_name>. Other committers should check +with a topic branch's creator before making any change to it. + +The simplest way to create a remote topic branch that works on all +versions of git is to push the current head as a new branch on the +remote, then check it out locally: + + $ branch="$yourname/$some_descriptive_name" + $ git push origin HEAD:$branch + $ git checkout -b $branch origin/$branch + +Users of git 1.7 or newer can do it in a more obvious manner: + + $ branch="$yourname/$some_descriptive_name" + $ git checkout -b $branch + $ git push origin -u $branch + +If you are not the creator of B<yourname>/B<some_descriptive_name>, you +might sometimes find that the original author has edited the branch's +history. There are lots of good reasons for this. Sometimes, an author +might simply be rebasing the branch onto a newer source point. +Sometimes, an author might have found an error in an early commit which +they wanted to fix before merging the branch to blead. + +Currently the master repository is configured to forbid +non-fast-forward merges. This means that the branches within can not be +rebased and pushed as a single step. + +The only way you will ever be allowed to rebase or modify the history +of a pushed branch is to delete it and push it as a new branch under +the same name. Please think carefully about doing this. It may be +better to sequentially rename your branches so that it is easier for +others working with you to cherry-pick their local changes onto the new +version. (XXX: needs explanation). + +If you want to rebase a personal topic branch, you will have to delete +your existing topic branch and push as a new version of it. You can do +this via the following formula (see the explanation about C<refspec>'s +in the git push documentation for details) after you have rebased your +branch: + + # first rebase + $ git checkout $user/$topic + $ git fetch + $ git rebase origin/blead + + # then "delete-and-push" + $ git push origin :$user/$topic + $ git push origin $user/$topic + +B<NOTE:> it is forbidden at the repository level to delete any of the +"primary" branches. That is any branch matching +C<m!^(blead|maint|perl)!>. Any attempt to do so will result in git +producing an error like this: + + $ git push origin :blead + *** It is forbidden to delete blead/maint branches in this repository + error: hooks/update exited with error code 1 + error: hook declined to update refs/heads/blead + To ssh://perl5.git.perl.org/perl + ! [remote rejected] blead (hook declined) + error: failed to push some refs to 'ssh://perl5.git.perl.org/perl' + +As a matter of policy we do B<not> edit the history of the blead and +maint-* branches. If a typo (or worse) sneaks into a commit to blead or +maint-*, we'll fix it in another commit. The only types of updates +allowed on these branches are "fast-forward's", where all history is +preserved. + +Annotated tags in the canonical perl.git repository will never be +deleted or modified. Think long and hard about whether you want to push +a local tag to perl.git before doing so. (Pushing unannotated tags is +not allowed.) + +=head1 WRITE ACCESS TO THE GIT REPOSITORY + +Once you have write access, you will need to modify the URL for the +origin remote to enable pushing. Edit F<.git/config> with the +git-config(1) command: + + % git config remote.origin.url ssh://perl5.git.perl.org/perl.git + +You can also set up your user name and e-mail address. Most people do +this once globally in their F<~/.gitconfig> by doing something like: + + % git config --global user.name "Ævar Arnfjörð Bjarmason" + % git config --global user.email avarab@gmail.com + +However if you'd like to override that just for perl then execute then +execute something like the following in F<perl>: + + % git config user.email avar@cpan.org + +It is also possible to keep C<origin> as a git remote, and add a new +remote for ssh access: + + % git remote add camel perl5.git.perl.org:/perl.git + +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: + + % git fetch camel + % git push camel + +The C<fetch> command just updates the C<camel> refs, as the objects +themselves should have been fetched when pulling from C<origin>. +=head1 Accepting a patch + +If you have received a patch file generated using the above section, +you should try out the patch. + +First we need to create a temporary new branch for these changes and +switch into it: + + % git checkout -b experimental + +Patches that were formatted by C<git format-patch> are applied with +C<git am>: + + % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch + Applying Rename Leon Brocard to Orange Brocard + +If just a raw diff is provided, it is also possible use this two-step +process: + + % git apply bugfix.diff + % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>" + +Now we can inspect the change: + + % git show HEAD + commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 + Author: Leon Brocard <acme@astray.com> + 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 <lhecking@nmrc.ucc.ie> + Laszlo Molnar <laszlo.molnar@eth.ericsson.se> + Leif Huhn <leif@hale.dkstat.com> + Len Johnson <lenjay@ibm.net> + -Leon Brocard <acme@astray.com> + +Orange Brocard <acme@astray.com> + Les Peters <lpeters@aol.net> + Lesley Binks <lesley.binks@gmail.com> + Lincoln D. Stein <lstein@cshl.org> + +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: + + % git checkout blead + % git merge experimental + % git push + +If you want to delete your temporary branch, you may do so with: + + % 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. + +=head2 Committing to blead + +The 'blead' branch will become the next production release of Perl. + +Before pushing I<any> local change to blead, it's incredibly important +that you do a few things, lest other committers come after you with +pitchforks and torches: + +=over + +=item * + +Make sure you have a good commit message. See L<perlhack/Commit +message> for details. + +=item * + +Run the test suite. You might not think that one typo fix would break a +test file. You'd be wrong. Here's an example of where not running the +suite caused problems. A patch was submitted that added a couple of +tests to an existing .t. It couldn't possibly affect anything else, so +no need to test beyond the single affected .t, right? But, the +submitter's email address had changed since the last of their +submissions, and this caused other tests to fail. Running the test +target given in the next item would have caught this problem. + +=item * + +If you don't run the full test suite, at least C<make test_porting>. +This will run basic sanity checks. To see which sanity checks, have a +look in F<t/porting>. + +=item * + +If you make any changes that affect miniperl or core routines that have +different code paths for miniperl, be sure to run C<make minitest>. +This will catch problems that even the full test suite will not catch +because it runs a subset of tests under miniperl rather than perl. + +=back + +=head2 Committing to maintenance versions + +Maintenance versions should only be altered to add critical bug fixes, +see L<perlpolicy>. + +To commit to a maintenance version of perl, you need to create a local +tracking branch: + + % git checkout --track -b maint-5.005 origin/maint-5.005 + +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. + +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. + +Before pushing any change to a maint version, make sure you've +satisfied the steps in L</Committing to blead> above. + +=head2 Grafts + +The perl history contains one mistake which was not caught in the +conversion: a merge was recorded in the history between blead and +maint-5.10 where no merge actually occurred. Due to the nature of git, +this is now impossible to fix in the public repository. You can remove +this mis-merge locally by adding the following line to your +C<.git/info/grafts> file: + + 296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930 + +It is particularly important to have this graft line if any bisecting +is done in the area of the "merge" in question. + +=head2 Merging from a branch via GitHub + +While we don't encourage the submission of patches via GitHub, that +will still happen. Here is a guide to merging patches from a GitHub +repository. + + % git remote add avar git://github.com/avar/perl.git + % git fetch avar + +Now you can see the differences between the branch and blead: + + % git diff avar/orange + +And you can see the commits: + + % git log avar/orange + +If you approve of a specific commit, you can cherry pick it: + + % git cherry-pick 0c24b290ae02b2ab3304f51d5e11e85eb3659eae + +Or you could just merge the whole branch if you like it all: + + % git merge avar/orange + +And then push back to the repository: + + % git push + +=head2 A note on camel and dromedary + +The committers have SSH access to the two servers that serve +C<perl5.git.perl.org>. One is C<perl5.git.perl.org> itself (I<camel>), +which is the 'master' repository. The second one is +C<users.perl5.git.perl.org> (I<dromedary>), 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 in /srv/CPAN, please use this. To share files +with the general public, dromedary serves your ~/public_html/ as +C<http://users.perl5.git.perl.org/~yourlogin/> + +These hosts have fairly strict firewalls to the outside. Outgoing, only +rsync, ssh and git are allowed. For http and ftp, you can use +http://webproxy:3128 as proxy. Incoming, the firewall tries to detect +attacks and blocks IP addresses with suspicious activity. This +sometimes (but very rarely) has false positives and you might get +blocked. The quickest way to get unblocked is to notify the admins. + +These two boxes are owned, hosted, and operated by booking.com. You can +reach the sysadmins in #p5p on irc.perl.org or via mail to +C<perl5-porters@perl.org>. |