Edit: /usr/share/perl5/pod/perlgit.pod (33509B)
=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
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.
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 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 these 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 which will be configured to merge from the
remote tracking branch C.
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 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 ..." to unstage)
modified: pod/perlgit.pod
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working
directory)
modified: pod/perlgit.pod
Untracked files:
(use "git add ..." 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 which has
not been pushed to the C remote yet. B: This output
is also what you see as a template if you do not provide a message to
C.
=head2 Patch workflow
First, please read L 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 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 ..." 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
Laszlo Molnar
Leif Huhn
Len Johnson
-Leon Brocard
+Orange Brocard
Les Peters
Lesley Binks
Lincoln D. Stein
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>> before doing the commit. C> 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, you should see something like this:
% git status
On branch orange
Untracked files:
(use "git add ..." 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 blead..
0001-Rename-Leon-Brocard-to-Orange-Brocard.patch
Or for a lot of changes, e.g. from a topic branch:
% git format-patch --stdout -M blead.. > topic-branch-changes.patch
You should now send an email to
L 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 directly if the
patch is not ready to be applied, but intended for discussion.
Please do not use git-send-email(1) to send your patch. See L for more information.
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 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 will start up your favorite text editor, so that you can craft a
commit message for your change. See L 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, you should see something like this:
% git status
On branch blead
Your branch is ahead of 'origin/blead' by 2 commits.
(use "git push" to publish your local commits)
Untracked files:
(use "git add ..." 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 Sending patch emails
After you've generated your patch you should send it
to L (as discussed L) with a normal mail client as an
attachment, along with a description of the patch.
You B use git-send-email(1) to send patches generated with
git-format-patch(1). The RT ticketing system living behind
L does not respect the inline
contents of E-Mails, sending an inline patch to RT guarantees that your
patch will be destroyed.
Someone may download your patch from RT, which will result in the
subject (the first line of the commit message) being omitted. See
L