=head1 SYNOPSIS
-All of Perl's source code is kept centrally in a Git repository. 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.
+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.
The full repository takes up about 80MB of disk space. A check out of
-the blead branch (that is, the master 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).
+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).
=head1 GETTING ACCESS TO THE REPOSITORY
=head2 READ ACCESS VIA THE WEB
-You may access this over the web. This allows you to browse the tree,
-see recent commits, search for particular commits and more. You may
-access it at:
+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:
http://perl5.git.perl.org/perl.git
+A mirror of the repository is found at:
+
+ http://github.com/github/perl
+
=head2 READ ACCESS VIA GIT
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):
- git clone git://perl5.git.perl.org/perl.git perl-git
+ % git clone git://perl5.git.perl.org/perl.git perl-git
This clones the repository and makes a local copy in the F<perl-git>
directory.
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):
+fetch a copy of the repository over HTTP (this is at least 4x slower):
- git clone http://perl5.git.perl.org/perl.git perl-http
+ % git clone http://perl5.git.perl.org/perl.git perl-http
This clones the repository and makes a local copy in the F<perl-http>
directory.
If you are a committer, then you can fetch a copy of the repository
that you can push back on with:
- git clone ssh://perl5.git.perl.org/gitroot/perl.git perl-ssh
+ % git clone ssh://perl5.git.perl.org/perl.git perl-ssh
This clones the repository and makes a local copy in the F<perl-ssh>
directory.
-If you clone using git, 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:
+If you cloned using the git protocol, which is faster than ssh, then
+you will need to modify the URL for the origin remote to enable
+pushing. To do that edit F<.git/config> with L<git-config(1)> like
+this:
- [remote "origin"]
- url = git://perl5.git.perl.org/perl.git
+ % git config remote.origin.url ssh://perl5.git.perl.org/perl.git
-change that to something like this:
+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:
- [remote "origin"]
- url = ssh://perl5.git.perl.org/gitroot/perl.git
+ % git config --global user.name "Ævar Arnfjörð Bjarmason"
+ % git config --global user.email avarab@gmail.com
-NOTE: there are symlinks set up so that the /gitroot is actually
-optional.
+However if you'd like to override that just for perl then execute then
+execute something like the following in F<perl-git>:
-You can also set up your user name and e-mail address. For example
-
- % git config user.name "Leon Brocard"
- % git config user.email acme@astray.com
+ % 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 user@camel:/gitroot/perl.git
+ % 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
The C<fetch> command just updates the C<camel> refs, as the objects
themselves should have been fetched when pulling from C<origin>.
+=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>
+
=head1 OVERVIEW OF THE REPOSITORY
Once you have changed into the repository directory, you can inspect
is also what you see as a template if you do not provide a message to
C<git commit>.
-Assuming we commit all the mentioned changes above:
+Assuming that you'd like to commit all the changes you've just made as a
+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</Commit message> below 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:
- % 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(-)
-We can re-run git status and see something like this:
+
+If you re-run C<git status>, you should see something like this:
% git status
# On branch blead
% 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 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:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
- # modified: AUTHORS
+ # modified: AUTHORS
#
And you can see the changes:
Now commit your change locally:
- % git add AUTHORS
- % git commit -m 'Rename Leon Brocard to Orange Brocard'
+ % 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(-)
+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 origin
0001-Rename-Leon-Brocard-to-Orange-Brocard.patch
You should now send an email to perl5-porters@perl.org with a
-description of your changes, and attach this patch file as an
-attachment.
+description of your changes, and include this patch file as an
+attachment. (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 branch -D orange
Deleted branch orange.
+=head2 Using git to send patch emails
+
+In your ~/git/perl repository, set the destination email to the
+perl5-porters mailing list.
+
+ $ 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
file that may have gotten copied while building the source
distribution, consult the C<MANIFEST>.
-=head2 A note on binary files
+As a special case, several files are regenerated by 'make regen' if
+your patch alters C<embed.fnc>. These are needed for compilation, but
+are included in the distribution so that you can build perl without
+needing another perl to generate the files. You must test with these
+regenerated files, but it is preferred that you instead note that
+'make regen is needed' in both the email and the commit message, and
+submit your patch without them. If you're submitting a series of
+patches, it might be best to submit the regenerated changes
+immediately after the source-changes that caused them, so as to have
+as little effect as possible on the bisectability of your patchset.
-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.
+=for XXX
-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:
+What should we recommend about binary files now? Do we need anything?
- $ 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
+=head2 Getting your patch accepted
-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.
+If you are submitting a code patch there are several things that
+you need to do.
-=head2 Getting your patch accepted
+=over 4
-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).
+=item Commit message
-If you are submitting a code patch there are several other things that
-you need to do.
+As you craft each patch you intend to submit to the Perl core, it's
+important to write a good commit message.
+
+Your commit message should start with a description of the problem that
+the patch corrects or new functionality that the patch adds.
+
+As a general rule of thumb, your commit message should let a programmer
+with a reasonable familiarity with the Perl core quickly understand what
+you were trying to do, how you were trying to do it and why the change
+matters to Perl.
=over 4
+=item What
+
+Your commit message should describe what part of the Perl core you're
+changing and what you expect your patch to do.
+
+=item Why
+
+Perhaps most importantly, your commit message should describe why the
+change you are making is important. When someone looks at your change
+in six months or six years, your intent should be clear. If you're
+deprecating a feature with the intent of later simplifying another bit
+of code, say so. If you're fixing a performance problem or adding a new
+feature to support some other bit of the core, mention that.
+
+=item How
+
+While it's not necessary for documentation changes, new tests or
+trivial patches, it's often worth explaining how your change works.
+Even if it's clear to you today, it may not be clear to a porter next
+month or next year.
+
+=back
+
+A commit message isn't intended to take the place of comments in your
+code. Commit messages should describe the change you made, while code
+comments should describe the current state of the code. If you've just
+implemented a new feature, complete with doc, tests and well-commented
+code, a brief commit message will often suffice. If, however, you've
+just changed a single character deep in the parser or lexer, you might
+need to write a small novel to ensure that future readers understand
+what you did and why you did it.
+
=item Comments, Comments, Comments
Be sure to adequately comment your code. While commenting every line
=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.
+If your patch changes code (rather than just changing documentation) you
+should also include one or more test cases which illustrate the bug you're
+fixing or validate the new functionality you're adding. In general,
+you should update an existing test file rather than create a new one.
+
Your testsuite additions should generally follow these guidelines
(courtesy of Gurusamy Sarathy <gsar@activestate.com>):
process:
% git apply bugfix.diff
- % git commit -am "Some fixing" --author="That Guy <that.guy@internets.com>"
+ % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>"
Now we can inspect the change:
- % git log
+ % 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
- ...
- % git diff blead
diff --git a/AUTHORS b/AUTHORS
index 293dd70..722c93e 100644
--- a/AUTHORS
=head1 CLEANING A WORKING DIRECTORY
The command C<git clean> can with varying arguments be used as a
-replacement for make-clean.
+replacement for C<make clean>.
To reset your working directory to a pristine condition you can do:
- git clean -dxf
+ % git clean -dxf
However, be aware this will delete ALL untracked content. You can use
- git clean -Xf
+ % 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.
+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>.
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. We need
+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:
#!/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" || exit 125
- make || exit 125
+ # 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 -j4 test_prep
+ [ -x ./perl ] || exit 125
./perl -Ilib ~/testcase.pl
+ ret=$?
+ [ $ret -gt 127 ] && ret=127
+ 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>.
-We first enter in bisect mode with:
+You first enter in bisect mode with:
% git bisect start
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>. We can then run the bisecting process with:
+C<perl-5.10.0>. You can then run the bisecting process with:
% git bisect run ~/run
% git clone git@github.com:USERNAME/perl.git perl-github
-We shall make the same patch as above, creating a new branch:
+The same patch as above, using github might look like this:
% 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 add AUTHORS
- % git commit -m 'Rename Leon Brocard to Orange Brocard'
+ % git commit -a -m 'Rename Leon Brocard to Orange Brocard'
% git push origin orange
The orange branch has been pushed to GitHub, so you should now send an
http://github.com/USERNAME/perl/tree/orange
git@github.com:USERNAME/perl.git branch orange
+=head1 MERGING FROM A BRANCH VIA GITHUB
+
+If someone has provided a branch via GitHub and you are a committer,
+you should use the following in your perl-ssh directory:
+
+ % git remote add dandv git://github.com/dandv/perl.git
+ % git fetch
+
+Now you can see the differences between the branch and blead:
+
+ % git diff dandv/blead
+
+And you can see the commits:
+
+ % git log dandv/blead
+
+If you approve of a specific commit, you can cherry pick it:
+
+ % git cherry-pick 3adac458cb1c1d41af47fc66e67b49c8dec2323f
+
+Or you could just merge the whole branch if you like it all:
+
+ % git merge dandv/blead
+
+And then push back to the repository:
+
+ % git push
+
+
+=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.
+
+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 COMMITTING TO MAINTENANCE VERSIONS
+Maintenance versions should only be altered to add critical bug fixes.
+
To commit to a maintenance version of perl, you need to create a local
tracking branch:
B<-x> option to C<git cherry-pick> in order to record the SHA1 of the
original commit in the new commit message.
+=head1 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.
+
+
+
=head1 SEE ALSO
The git documentation, accessible via C<git help command>.
https://perl5.git.perl.org / perl5.git / blobdiff