| 1 | =encoding utf8 |
| 2 | |
| 3 | =for comment |
| 4 | Consistent formatting of this file is achieved with: |
| 5 | perl ./Porting/podtidy pod/perlgit.pod |
| 6 | |
| 7 | =head1 NAME |
| 8 | |
| 9 | perlgit - Detailed information about git and the Perl repository |
| 10 | |
| 11 | =head1 DESCRIPTION |
| 12 | |
| 13 | This document provides details on using git to develop Perl. If you are |
| 14 | just interested in working on a quick patch, see L<perlhack> first. |
| 15 | This document is intended for people who are regular contributors to |
| 16 | Perl, including those with write access to the git repository. |
| 17 | |
| 18 | =head1 CLONING THE REPOSITORY |
| 19 | |
| 20 | All of Perl's source code is kept centrally in a Git repository at |
| 21 | I<perl5.git.perl.org>. |
| 22 | |
| 23 | You can make a read-only clone of the repository by running: |
| 24 | |
| 25 | % git clone git://perl5.git.perl.org/perl.git perl |
| 26 | |
| 27 | This uses the git protocol (port 9418). |
| 28 | |
| 29 | If you cannot use the git protocol for firewall reasons, you can also |
| 30 | clone via http, though this is much slower: |
| 31 | |
| 32 | % git clone http://perl5.git.perl.org/perl.git perl |
| 33 | |
| 34 | =head1 WORKING WITH THE REPOSITORY |
| 35 | |
| 36 | Once you have changed into the repository directory, you can inspect |
| 37 | it. After a clone the repository will contain a single local branch, |
| 38 | which will be the current branch as well, as indicated by the asterisk. |
| 39 | |
| 40 | % git branch |
| 41 | * blead |
| 42 | |
| 43 | Using the -a switch to C<branch> will also show the remote tracking |
| 44 | branches in the repository: |
| 45 | |
| 46 | % git branch -a |
| 47 | * blead |
| 48 | origin/HEAD |
| 49 | origin/blead |
| 50 | ... |
| 51 | |
| 52 | The branches that begin with "origin" correspond to the "git remote" |
| 53 | that you cloned from (which is named "origin"). Each branch on the |
| 54 | remote will be exactly tracked by these branches. You should NEVER do |
| 55 | work on these remote tracking branches. You only ever do work in a |
| 56 | local branch. Local branches can be configured to automerge (on pull) |
| 57 | from a designated remote tracking branch. This is the case with the |
| 58 | default branch C<blead> which will be configured to merge from the |
| 59 | remote tracking branch C<origin/blead>. |
| 60 | |
| 61 | You can see recent commits: |
| 62 | |
| 63 | % git log |
| 64 | |
| 65 | And pull new changes from the repository, and update your local |
| 66 | repository (must be clean first) |
| 67 | |
| 68 | % git pull |
| 69 | |
| 70 | Assuming we are on the branch C<blead> immediately after a pull, this |
| 71 | command would be more or less equivalent to: |
| 72 | |
| 73 | % git fetch |
| 74 | % git merge origin/blead |
| 75 | |
| 76 | In fact if you want to update your local repository without touching |
| 77 | your working directory you do: |
| 78 | |
| 79 | % git fetch |
| 80 | |
| 81 | And if you want to update your remote-tracking branches for all defined |
| 82 | remotes simultaneously you can do |
| 83 | |
| 84 | % git remote update |
| 85 | |
| 86 | Neither of these last two commands will update your working directory, |
| 87 | however both will update the remote-tracking branches in your |
| 88 | repository. |
| 89 | |
| 90 | To make a local branch of a remote branch: |
| 91 | |
| 92 | % git checkout -b maint-5.10 origin/maint-5.10 |
| 93 | |
| 94 | To switch back to blead: |
| 95 | |
| 96 | % git checkout blead |
| 97 | |
| 98 | =head2 Finding out your status |
| 99 | |
| 100 | The most common git command you will use will probably be |
| 101 | |
| 102 | % git status |
| 103 | |
| 104 | This command will produce as output a description of the current state |
| 105 | of the repository, including modified files and unignored untracked |
| 106 | files, and in addition it will show things like what files have been |
| 107 | staged for the next commit, and usually some useful information about |
| 108 | how to change things. For instance the following: |
| 109 | |
| 110 | $ git status |
| 111 | # On branch blead |
| 112 | # Your branch is ahead of 'origin/blead' by 1 commit. |
| 113 | # |
| 114 | # Changes to be committed: |
| 115 | # (use "git reset HEAD <file>..." to unstage) |
| 116 | # |
| 117 | # modified: pod/perlgit.pod |
| 118 | # |
| 119 | # Changed but not updated: |
| 120 | # (use "git add <file>..." to update what will be committed) |
| 121 | # |
| 122 | # modified: pod/perlgit.pod |
| 123 | # |
| 124 | # Untracked files: |
| 125 | # (use "git add <file>..." to include in what will be committed) |
| 126 | # |
| 127 | # deliberate.untracked |
| 128 | |
| 129 | This shows that there were changes to this document staged for commit, |
| 130 | and that there were further changes in the working directory not yet |
| 131 | staged. It also shows that there was an untracked file in the working |
| 132 | directory, and as you can see shows how to change all of this. It also |
| 133 | shows that there is one commit on the working branch C<blead> which has |
| 134 | not been pushed to the C<origin> remote yet. B<NOTE>: that this output |
| 135 | is also what you see as a template if you do not provide a message to |
| 136 | C<git commit>. |
| 137 | |
| 138 | =head2 Patch workflow |
| 139 | |
| 140 | First, please read L<perlhack> for details on hacking the Perl core. |
| 141 | That document covers many details on how to create a good patch. |
| 142 | |
| 143 | If you already have a Perl repository, you should ensure that you're on |
| 144 | the I<blead> branch, and your repository is up to date: |
| 145 | |
| 146 | % git checkout blead |
| 147 | % git pull |
| 148 | |
| 149 | It's preferable to patch against the latest blead version, since this |
| 150 | is where new development occurs for all changes other than critical bug |
| 151 | fixes. Critical bug fix patches should be made against the relevant |
| 152 | maint branches, or should be submitted with a note indicating all the |
| 153 | branches where the fix should be applied. |
| 154 | |
| 155 | Now that we have everything up to date, we need to create a temporary |
| 156 | new branch for these changes and switch into it: |
| 157 | |
| 158 | % git checkout -b orange |
| 159 | |
| 160 | which is the short form of |
| 161 | |
| 162 | % git branch orange |
| 163 | % git checkout orange |
| 164 | |
| 165 | Creating a topic branch makes it easier for the maintainers to rebase |
| 166 | or merge back into the master blead for a more linear history. If you |
| 167 | don't work on a topic branch the maintainer has to manually cherry pick |
| 168 | your changes onto blead before they can be applied. |
| 169 | |
| 170 | That'll get you scolded on perl5-porters, so don't do that. Be Awesome. |
| 171 | |
| 172 | Then make your changes. For example, if Leon Brocard changes his name |
| 173 | to Orange Brocard, we should change his name in the AUTHORS file: |
| 174 | |
| 175 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS |
| 176 | |
| 177 | You can see what files are changed: |
| 178 | |
| 179 | % git status |
| 180 | # On branch orange |
| 181 | # Changes to be committed: |
| 182 | # (use "git reset HEAD <file>..." to unstage) |
| 183 | # |
| 184 | # modified: AUTHORS |
| 185 | # |
| 186 | |
| 187 | And you can see the changes: |
| 188 | |
| 189 | % git diff |
| 190 | diff --git a/AUTHORS b/AUTHORS |
| 191 | index 293dd70..722c93e 100644 |
| 192 | --- a/AUTHORS |
| 193 | +++ b/AUTHORS |
| 194 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
| 195 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
| 196 | Leif Huhn <leif@hale.dkstat.com> |
| 197 | Len Johnson <lenjay@ibm.net> |
| 198 | -Leon Brocard <acme@astray.com> |
| 199 | +Orange Brocard <acme@astray.com> |
| 200 | Les Peters <lpeters@aol.net> |
| 201 | Lesley Binks <lesley.binks@gmail.com> |
| 202 | Lincoln D. Stein <lstein@cshl.org> |
| 203 | |
| 204 | Now commit your change locally: |
| 205 | |
| 206 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
| 207 | Created commit 6196c1d: Rename Leon Brocard to Orange Brocard |
| 208 | 1 files changed, 1 insertions(+), 1 deletions(-) |
| 209 | |
| 210 | The C<-a> option is used to include all files that git tracks that you |
| 211 | have changed. If at this time, you only want to commit some of the |
| 212 | files you have worked on, you can omit the C<-a> and use the command |
| 213 | C<S<git add I<FILE ...>>> before doing the commit. C<S<git add |
| 214 | --interactive>> allows you to even just commit portions of files |
| 215 | instead of all the changes in them. |
| 216 | |
| 217 | The C<-m> option is used to specify the commit message. If you omit it, |
| 218 | git will open a text editor for you to compose the message |
| 219 | interactively. This is useful when the changes are more complex than |
| 220 | the sample given here, and, depending on the editor, to know that the |
| 221 | first line of the commit message doesn't exceed the 50 character legal |
| 222 | maximum. |
| 223 | |
| 224 | Once you've finished writing your commit message and exited your |
| 225 | editor, git will write your change to disk and tell you something like |
| 226 | this: |
| 227 | |
| 228 | Created commit daf8e63: explain git status and stuff about remotes |
| 229 | 1 files changed, 83 insertions(+), 3 deletions(-) |
| 230 | |
| 231 | If you re-run C<git status>, you should see something like this: |
| 232 | |
| 233 | % git status |
| 234 | # On branch blead |
| 235 | # Your branch is ahead of 'origin/blead' by 2 commits. |
| 236 | # |
| 237 | # Untracked files: |
| 238 | # (use "git add <file>..." to include in what will be committed) |
| 239 | # |
| 240 | # deliberate.untracked |
| 241 | nothing added to commit but untracked files present (use "git add" to track) |
| 242 | |
| 243 | When in doubt, before you do anything else, check your status and read |
| 244 | it carefully, many questions are answered directly by the git status |
| 245 | output. |
| 246 | |
| 247 | You can examine your last commit with: |
| 248 | |
| 249 | % git show HEAD |
| 250 | |
| 251 | and if you are not happy with either the description or the patch |
| 252 | itself you can fix it up by editing the files once more and then issue: |
| 253 | |
| 254 | % git commit -a --amend |
| 255 | |
| 256 | Now you should create a patch file for all your local changes: |
| 257 | |
| 258 | % git format-patch -M origin.. |
| 259 | 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
| 260 | |
| 261 | Or for a lot of changes, e.g. from a topic branch: |
| 262 | |
| 263 | % git format-patch --stdout -M origin.. > topic-branch-changes.patch |
| 264 | |
| 265 | You should now send an email to |
| 266 | L<perlbug@perl.org|mailto:perlbug@perl.org> with a description of your |
| 267 | changes, and include this patch file as an attachment. In addition to |
| 268 | being tracked by RT, mail to perlbug will automatically be forwarded to |
| 269 | perl5-porters (with manual moderation, so please be patient). You |
| 270 | should only send patches to |
| 271 | L<perl5-porters@perl.org|mailto:perl5-porters@perl.org> directly if the |
| 272 | patch is not ready to be applied, but intended for discussion. |
| 273 | |
| 274 | See the next section for how to configure and use git to send these |
| 275 | emails for you. |
| 276 | |
| 277 | If you want to delete your temporary branch, you may do so with: |
| 278 | |
| 279 | % git checkout blead |
| 280 | % git branch -d orange |
| 281 | error: The branch 'orange' is not an ancestor of your current HEAD. |
| 282 | If you are sure you want to delete it, run 'git branch -D orange'. |
| 283 | % git branch -D orange |
| 284 | Deleted branch orange. |
| 285 | |
| 286 | =head2 Committing your changes |
| 287 | |
| 288 | Assuming that you'd like to commit all the changes you've made as a |
| 289 | single atomic unit, run this command: |
| 290 | |
| 291 | % git commit -a |
| 292 | |
| 293 | (That C<-a> tells git to add every file you've changed to this commit. |
| 294 | New files aren't automatically added to your commit when you use |
| 295 | C<commit -a> If you want to add files or to commit some, but not all of |
| 296 | your changes, have a look at the documentation for C<git add>.) |
| 297 | |
| 298 | Git will start up your favorite text editor, so that you can craft a |
| 299 | commit message for your change. See L<perlhack/Commit message> for more |
| 300 | information about what makes a good commit message. |
| 301 | |
| 302 | Once you've finished writing your commit message and exited your |
| 303 | editor, git will write your change to disk and tell you something like |
| 304 | this: |
| 305 | |
| 306 | Created commit daf8e63: explain git status and stuff about remotes |
| 307 | 1 files changed, 83 insertions(+), 3 deletions(-) |
| 308 | |
| 309 | If you re-run C<git status>, you should see something like this: |
| 310 | |
| 311 | % git status |
| 312 | # On branch blead |
| 313 | # Your branch is ahead of 'origin/blead' by 2 commits. |
| 314 | # |
| 315 | # Untracked files: |
| 316 | # (use "git add <file>..." to include in what will be committed) |
| 317 | # |
| 318 | # deliberate.untracked |
| 319 | nothing added to commit but untracked files present (use "git add" to track) |
| 320 | |
| 321 | When in doubt, before you do anything else, check your status and read |
| 322 | it carefully, many questions are answered directly by the git status |
| 323 | output. |
| 324 | |
| 325 | =head2 Sending patch emails |
| 326 | |
| 327 | After you've generated your patch you should sent it |
| 328 | to perlbug@perl.org (as discussed L<in the previous |
| 329 | section|/"Patch workflow"> with a normal mail client as an |
| 330 | attachment, along with a description of the patch. |
| 331 | |
| 332 | You B<must not> use git-send-email(1) to send patches generated with |
| 333 | git-format-patch(1). The RT ticketing system living behind |
| 334 | perlbug@perl.org does not respect the inline contents of E-Mails, |
| 335 | sending an inline patch to RT guarantees that your patch will be |
| 336 | destroyed. |
| 337 | |
| 338 | Someone may download your patch from RT, which will result in the |
| 339 | subject (the first line of the commit message) being omitted. See RT |
| 340 | #74192 and commit a4583001 for an example. Alternatively someone may |
| 341 | apply your patch from RT after it arrived in their mailbox, by which |
| 342 | time RT will have modified the inline content of the message. See RT |
| 343 | #74532 and commit f9bcfeac for a bad example of this failure mode. |
| 344 | |
| 345 | =head2 A note on derived files |
| 346 | |
| 347 | Be aware that many files in the distribution are derivative--avoid |
| 348 | patching them, because git won't see the changes to them, and the build |
| 349 | process will overwrite them. Patch the originals instead. Most |
| 350 | utilities (like perldoc) are in this category, i.e. patch |
| 351 | F<utils/perldoc.PL> rather than F<utils/perldoc>. Similarly, don't |
| 352 | create patches for files under $src_root/ext from their copies found in |
| 353 | $install_root/lib. If you are unsure about the proper location of a |
| 354 | file that may have gotten copied while building the source |
| 355 | distribution, consult the C<MANIFEST>. |
| 356 | |
| 357 | =head2 Cleaning a working directory |
| 358 | |
| 359 | The command C<git clean> can with varying arguments be used as a |
| 360 | replacement for C<make clean>. |
| 361 | |
| 362 | To reset your working directory to a pristine condition you can do: |
| 363 | |
| 364 | % git clean -dxf |
| 365 | |
| 366 | However, be aware this will delete ALL untracked content. You can use |
| 367 | |
| 368 | % git clean -Xf |
| 369 | |
| 370 | to remove all ignored untracked files, such as build and test |
| 371 | byproduct, but leave any manually created files alone. |
| 372 | |
| 373 | If you only want to cancel some uncommitted edits, you can use C<git |
| 374 | checkout> and give it a list of files to be reverted, or C<git checkout |
| 375 | -f> to revert them all. |
| 376 | |
| 377 | If you want to cancel one or several commits, you can use C<git reset>. |
| 378 | |
| 379 | =head2 Bisecting |
| 380 | |
| 381 | C<git> provides a built-in way to determine which commit should be blamed |
| 382 | for introducing a given bug. C<git bisect> performs a binary search of |
| 383 | history to locate the first failing commit. It is fast, powerful and |
| 384 | flexible, but requires some setup and to automate the process an auxiliary |
| 385 | shell script is needed. |
| 386 | |
| 387 | The core provides a wrapper program, F<Porting/bisect.pl>, which attempts to |
| 388 | simplify as much as possible, making bisecting as simple as running a Perl |
| 389 | one-liner. For example, if you want to know when this became an error: |
| 390 | |
| 391 | perl -e 'my $a := 2' |
| 392 | |
| 393 | you simply run this: |
| 394 | |
| 395 | .../Porting/bisect.pl -e 'my $a := 2;' |
| 396 | |
| 397 | Using C<bisect.pl>, with one command (and no other files) it's easy to find |
| 398 | out |
| 399 | |
| 400 | =over 4 |
| 401 | |
| 402 | =item * |
| 403 | |
| 404 | Which commit caused this example code to break? |
| 405 | |
| 406 | =item * |
| 407 | |
| 408 | Which commit caused this example code to start working? |
| 409 | |
| 410 | =item * |
| 411 | |
| 412 | Which commit added the first file to match this regex? |
| 413 | |
| 414 | =item * |
| 415 | |
| 416 | Which commit removed the last file to match this regex? |
| 417 | |
| 418 | =back |
| 419 | |
| 420 | usually without needing to know which versions of perl to use as start and |
| 421 | end revisions, as F<bisect.pl> automatically searches to find the earliest |
| 422 | stable version for which the test case passes. Run |
| 423 | C<Porting/bisect.pl --help> for the full documentation, including how to |
| 424 | set the C<Configure> and build time options. |
| 425 | |
| 426 | If you require more flexibility than F<Porting/bisect.pl> has to offer, you'll |
| 427 | need to run C<git bisect> yourself. It's most useful to use C<git bisect run> |
| 428 | to automate the building and testing of perl revisions. For this you'll need |
| 429 | a shell script for C<git> to call to test a particular revision. An example |
| 430 | script is F<Porting/bisect-example.sh>, which you should copy B<outside> of |
| 431 | the repository, as the bisect process will reset the state to a clean checkout |
| 432 | as it runs. The instructions below assume that you copied it as F<~/run> and |
| 433 | then edited it as appropriate. |
| 434 | |
| 435 | You first enter in bisect mode with: |
| 436 | |
| 437 | % git bisect start |
| 438 | |
| 439 | For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, |
| 440 | C<git> will learn about this when you enter: |
| 441 | |
| 442 | % git bisect bad |
| 443 | % git bisect good perl-5.10.0 |
| 444 | Bisecting: 853 revisions left to test after this |
| 445 | |
| 446 | This results in checking out the median commit between C<HEAD> and |
| 447 | C<perl-5.10.0>. You can then run the bisecting process with: |
| 448 | |
| 449 | % git bisect run ~/run |
| 450 | |
| 451 | When the first bad commit is isolated, C<git bisect> will tell you so: |
| 452 | |
| 453 | ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit |
| 454 | commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 |
| 455 | Author: Dave Mitchell <davem@fdisolutions.com> |
| 456 | Date: Sat Feb 9 14:56:23 2008 +0000 |
| 457 | |
| 458 | [perl #49472] Attributes + Unknown Error |
| 459 | ... |
| 460 | |
| 461 | bisect run success |
| 462 | |
| 463 | You can peek into the bisecting process with C<git bisect log> and |
| 464 | C<git bisect visualize>. C<git bisect reset> will get you out of bisect |
| 465 | mode. |
| 466 | |
| 467 | Please note that the first C<good> state must be an ancestor of the |
| 468 | first C<bad> state. If you want to search for the commit that I<solved> |
| 469 | some bug, you have to negate your test case (i.e. exit with C<1> if OK |
| 470 | and C<0> if not) and still mark the lower bound as C<good> and the |
| 471 | upper as C<bad>. The "first bad commit" has then to be understood as |
| 472 | the "first commit where the bug is solved". |
| 473 | |
| 474 | C<git help bisect> has much more information on how you can tweak your |
| 475 | binary searches. |
| 476 | |
| 477 | =head2 Topic branches and rewriting history |
| 478 | |
| 479 | Individual committers should create topic branches under |
| 480 | B<yourname>/B<some_descriptive_name>. Other committers should check |
| 481 | with a topic branch's creator before making any change to it. |
| 482 | |
| 483 | The simplest way to create a remote topic branch that works on all |
| 484 | versions of git is to push the current head as a new branch on the |
| 485 | remote, then check it out locally: |
| 486 | |
| 487 | $ branch="$yourname/$some_descriptive_name" |
| 488 | $ git push origin HEAD:$branch |
| 489 | $ git checkout -b $branch origin/$branch |
| 490 | |
| 491 | Users of git 1.7 or newer can do it in a more obvious manner: |
| 492 | |
| 493 | $ branch="$yourname/$some_descriptive_name" |
| 494 | $ git checkout -b $branch |
| 495 | $ git push origin -u $branch |
| 496 | |
| 497 | If you are not the creator of B<yourname>/B<some_descriptive_name>, you |
| 498 | might sometimes find that the original author has edited the branch's |
| 499 | history. There are lots of good reasons for this. Sometimes, an author |
| 500 | might simply be rebasing the branch onto a newer source point. |
| 501 | Sometimes, an author might have found an error in an early commit which |
| 502 | they wanted to fix before merging the branch to blead. |
| 503 | |
| 504 | Currently the master repository is configured to forbid |
| 505 | non-fast-forward merges. This means that the branches within can not be |
| 506 | rebased and pushed as a single step. |
| 507 | |
| 508 | The only way you will ever be allowed to rebase or modify the history |
| 509 | of a pushed branch is to delete it and push it as a new branch under |
| 510 | the same name. Please think carefully about doing this. It may be |
| 511 | better to sequentially rename your branches so that it is easier for |
| 512 | others working with you to cherry-pick their local changes onto the new |
| 513 | version. (XXX: needs explanation). |
| 514 | |
| 515 | If you want to rebase a personal topic branch, you will have to delete |
| 516 | your existing topic branch and push as a new version of it. You can do |
| 517 | this via the following formula (see the explanation about C<refspec>'s |
| 518 | in the git push documentation for details) after you have rebased your |
| 519 | branch: |
| 520 | |
| 521 | # first rebase |
| 522 | $ git checkout $user/$topic |
| 523 | $ git fetch |
| 524 | $ git rebase origin/blead |
| 525 | |
| 526 | # then "delete-and-push" |
| 527 | $ git push origin :$user/$topic |
| 528 | $ git push origin $user/$topic |
| 529 | |
| 530 | B<NOTE:> it is forbidden at the repository level to delete any of the |
| 531 | "primary" branches. That is any branch matching |
| 532 | C<m!^(blead|maint|perl)!>. Any attempt to do so will result in git |
| 533 | producing an error like this: |
| 534 | |
| 535 | $ git push origin :blead |
| 536 | *** It is forbidden to delete blead/maint branches in this repository |
| 537 | error: hooks/update exited with error code 1 |
| 538 | error: hook declined to update refs/heads/blead |
| 539 | To ssh://perl5.git.perl.org/perl |
| 540 | ! [remote rejected] blead (hook declined) |
| 541 | error: failed to push some refs to 'ssh://perl5.git.perl.org/perl' |
| 542 | |
| 543 | As a matter of policy we do B<not> edit the history of the blead and |
| 544 | maint-* branches. If a typo (or worse) sneaks into a commit to blead or |
| 545 | maint-*, we'll fix it in another commit. The only types of updates |
| 546 | allowed on these branches are "fast-forward's", where all history is |
| 547 | preserved. |
| 548 | |
| 549 | Annotated tags in the canonical perl.git repository will never be |
| 550 | deleted or modified. Think long and hard about whether you want to push |
| 551 | a local tag to perl.git before doing so. (Pushing unannotated tags is |
| 552 | not allowed.) |
| 553 | |
| 554 | =head2 Grafts |
| 555 | |
| 556 | The perl history contains one mistake which was not caught in the |
| 557 | conversion: a merge was recorded in the history between blead and |
| 558 | maint-5.10 where no merge actually occurred. Due to the nature of git, |
| 559 | this is now impossible to fix in the public repository. You can remove |
| 560 | this mis-merge locally by adding the following line to your |
| 561 | C<.git/info/grafts> file: |
| 562 | |
| 563 | 296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930 |
| 564 | |
| 565 | It is particularly important to have this graft line if any bisecting |
| 566 | is done in the area of the "merge" in question. |
| 567 | |
| 568 | =head1 WRITE ACCESS TO THE GIT REPOSITORY |
| 569 | |
| 570 | Once you have write access, you will need to modify the URL for the |
| 571 | origin remote to enable pushing. Edit F<.git/config> with the |
| 572 | git-config(1) command: |
| 573 | |
| 574 | % git config remote.origin.url ssh://perl5.git.perl.org/perl.git |
| 575 | |
| 576 | You can also set up your user name and e-mail address. Most people do |
| 577 | this once globally in their F<~/.gitconfig> by doing something like: |
| 578 | |
| 579 | % git config --global user.name "Ævar Arnfjörð Bjarmason" |
| 580 | % git config --global user.email avarab@gmail.com |
| 581 | |
| 582 | However, if you'd like to override that just for perl, |
| 583 | execute something like the following in F<perl>: |
| 584 | |
| 585 | % git config user.email avar@cpan.org |
| 586 | |
| 587 | It is also possible to keep C<origin> as a git remote, and add a new |
| 588 | remote for ssh access: |
| 589 | |
| 590 | % git remote add camel perl5.git.perl.org:/perl.git |
| 591 | |
| 592 | This allows you to update your local repository by pulling from |
| 593 | C<origin>, which is faster and doesn't require you to authenticate, and |
| 594 | to push your changes back with the C<camel> remote: |
| 595 | |
| 596 | % git fetch camel |
| 597 | % git push camel |
| 598 | |
| 599 | The C<fetch> command just updates the C<camel> refs, as the objects |
| 600 | themselves should have been fetched when pulling from C<origin>. |
| 601 | |
| 602 | =head2 Accepting a patch |
| 603 | |
| 604 | If you have received a patch file generated using the above section, |
| 605 | you should try out the patch. |
| 606 | |
| 607 | First we need to create a temporary new branch for these changes and |
| 608 | switch into it: |
| 609 | |
| 610 | % git checkout -b experimental |
| 611 | |
| 612 | Patches that were formatted by C<git format-patch> are applied with |
| 613 | C<git am>: |
| 614 | |
| 615 | % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
| 616 | Applying Rename Leon Brocard to Orange Brocard |
| 617 | |
| 618 | If just a raw diff is provided, it is also possible use this two-step |
| 619 | process: |
| 620 | |
| 621 | % git apply bugfix.diff |
| 622 | % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>" |
| 623 | |
| 624 | Now we can inspect the change: |
| 625 | |
| 626 | % git show HEAD |
| 627 | commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 |
| 628 | Author: Leon Brocard <acme@astray.com> |
| 629 | Date: Fri Dec 19 17:02:59 2008 +0000 |
| 630 | |
| 631 | Rename Leon Brocard to Orange Brocard |
| 632 | |
| 633 | diff --git a/AUTHORS b/AUTHORS |
| 634 | index 293dd70..722c93e 100644 |
| 635 | --- a/AUTHORS |
| 636 | +++ b/AUTHORS |
| 637 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
| 638 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
| 639 | Leif Huhn <leif@hale.dkstat.com> |
| 640 | Len Johnson <lenjay@ibm.net> |
| 641 | -Leon Brocard <acme@astray.com> |
| 642 | +Orange Brocard <acme@astray.com> |
| 643 | Les Peters <lpeters@aol.net> |
| 644 | Lesley Binks <lesley.binks@gmail.com> |
| 645 | Lincoln D. Stein <lstein@cshl.org> |
| 646 | |
| 647 | If you are a committer to Perl and you think the patch is good, you can |
| 648 | then merge it into blead then push it out to the main repository: |
| 649 | |
| 650 | % git checkout blead |
| 651 | % git merge experimental |
| 652 | % git push origin blead |
| 653 | |
| 654 | If you want to delete your temporary branch, you may do so with: |
| 655 | |
| 656 | % git checkout blead |
| 657 | % git branch -d experimental |
| 658 | error: The branch 'experimental' is not an ancestor of your current HEAD. |
| 659 | If you are sure you want to delete it, run 'git branch -D experimental'. |
| 660 | % git branch -D experimental |
| 661 | Deleted branch experimental. |
| 662 | |
| 663 | =head2 Committing to blead |
| 664 | |
| 665 | The 'blead' branch will become the next production release of Perl. |
| 666 | |
| 667 | Before pushing I<any> local change to blead, it's incredibly important |
| 668 | that you do a few things, lest other committers come after you with |
| 669 | pitchforks and torches: |
| 670 | |
| 671 | =over |
| 672 | |
| 673 | =item * |
| 674 | |
| 675 | Make sure you have a good commit message. See L<perlhack/Commit |
| 676 | message> for details. |
| 677 | |
| 678 | =item * |
| 679 | |
| 680 | Run the test suite. You might not think that one typo fix would break a |
| 681 | test file. You'd be wrong. Here's an example of where not running the |
| 682 | suite caused problems. A patch was submitted that added a couple of |
| 683 | tests to an existing .t. It couldn't possibly affect anything else, so |
| 684 | no need to test beyond the single affected .t, right? But, the |
| 685 | submitter's email address had changed since the last of their |
| 686 | submissions, and this caused other tests to fail. Running the test |
| 687 | target given in the next item would have caught this problem. |
| 688 | |
| 689 | =item * |
| 690 | |
| 691 | If you don't run the full test suite, at least C<make test_porting>. |
| 692 | This will run basic sanity checks. To see which sanity checks, have a |
| 693 | look in F<t/porting>. |
| 694 | |
| 695 | =item * |
| 696 | |
| 697 | If you make any changes that affect miniperl or core routines that have |
| 698 | different code paths for miniperl, be sure to run C<make minitest>. |
| 699 | This will catch problems that even the full test suite will not catch |
| 700 | because it runs a subset of tests under miniperl rather than perl. |
| 701 | |
| 702 | =back |
| 703 | |
| 704 | =head2 On merging and rebasing |
| 705 | |
| 706 | Simple, one-off commits pushed to the 'blead' branch should be simple |
| 707 | commits that apply cleanly. In other words, you should make sure your |
| 708 | work is committed against the current position of blead, so that you can |
| 709 | push back to the master repository without merging. |
| 710 | |
| 711 | Sometimes, blead will move while you're building or testing your |
| 712 | changes. When this happens, your push will be rejected with a message |
| 713 | like this: |
| 714 | |
| 715 | To ssh://perl5.git.perl.org/perl.git |
| 716 | ! [rejected] blead -> blead (non-fast-forward) |
| 717 | error: failed to push some refs to 'ssh://perl5.git.perl.org/perl.git' |
| 718 | To prevent you from losing history, non-fast-forward updates were rejected |
| 719 | Merge the remote changes (e.g. 'git pull') before pushing again. See the |
| 720 | 'Note about fast-forwards' section of 'git push --help' for details. |
| 721 | |
| 722 | When this happens, you can just I<rebase> your work against the new |
| 723 | position of blead, like this (assuming your remote for the master |
| 724 | repository is "p5p"): |
| 725 | |
| 726 | $ git fetch p5p |
| 727 | $ git rebase p5p/blead |
| 728 | |
| 729 | You will see your commits being re-applied, and you will then be able to |
| 730 | push safely. More information about rebasing can be found in the |
| 731 | documentation for the git-rebase(1) command. |
| 732 | |
| 733 | For larger sets of commits that only make sense together, or that would |
| 734 | benefit from a summary of the set's purpose, you should use a merge |
| 735 | commit. You should perform your work on a L<topic branch|/Topic |
| 736 | branches and rewriting history>, which you should regularly rebase |
| 737 | against blead to ensure that your code is not broken by blead moving. |
| 738 | When you have finished your work, please perform a final rebase and |
| 739 | test. Linear history is something that gets lost with every |
| 740 | commit on blead, but a final rebase makes the history linear |
| 741 | again, making it easier for future maintainers to see what has |
| 742 | happened. Rebase as follows (assuming your work was on the |
| 743 | branch C<< committer/somework >>): |
| 744 | |
| 745 | $ git checkout committer/somework |
| 746 | $ git rebase blead |
| 747 | |
| 748 | Then you can merge it into master like this: |
| 749 | |
| 750 | $ git checkout blead |
| 751 | $ git merge --no-ff --no-commit committer/somework |
| 752 | $ git commit -a |
| 753 | |
| 754 | The switches above deserve explanation. C<--no-ff> indicates that even |
| 755 | if all your work can be applied linearly against blead, a merge commit |
| 756 | should still be prepared. This ensures that all your work will be shown |
| 757 | as a side branch, with all its commits merged into the mainstream blead |
| 758 | by the merge commit. |
| 759 | |
| 760 | C<--no-commit> means that the merge commit will be I<prepared> but not |
| 761 | I<committed>. The commit is then actually performed when you run the |
| 762 | next command, which will bring up your editor to describe the commit. |
| 763 | Without C<--no-commit>, the commit would be made with nearly no useful |
| 764 | message, which would greatly diminish the value of the merge commit as a |
| 765 | placeholder for the work's description. |
| 766 | |
| 767 | When describing the merge commit, explain the purpose of the branch, and |
| 768 | keep in mind that this description will probably be used by the |
| 769 | eventual release engineer when reviewing the next perldelta document. |
| 770 | |
| 771 | =head2 Committing to maintenance versions |
| 772 | |
| 773 | Maintenance versions should only be altered to add critical bug fixes, |
| 774 | see L<perlpolicy>. |
| 775 | |
| 776 | To commit to a maintenance version of perl, you need to create a local |
| 777 | tracking branch: |
| 778 | |
| 779 | % git checkout --track -b maint-5.005 origin/maint-5.005 |
| 780 | |
| 781 | This creates a local branch named C<maint-5.005>, which tracks the |
| 782 | remote branch C<origin/maint-5.005>. Then you can pull, commit, merge |
| 783 | and push as before. |
| 784 | |
| 785 | You can also cherry-pick commits from blead and another branch, by |
| 786 | using the C<git cherry-pick> command. It is recommended to use the |
| 787 | B<-x> option to C<git cherry-pick> in order to record the SHA1 of the |
| 788 | original commit in the new commit message. |
| 789 | |
| 790 | Before pushing any change to a maint version, make sure you've |
| 791 | satisfied the steps in L</Committing to blead> above. |
| 792 | |
| 793 | =head2 Merging from a branch via GitHub |
| 794 | |
| 795 | While we don't encourage the submission of patches via GitHub, that |
| 796 | will still happen. Here is a guide to merging patches from a GitHub |
| 797 | repository. |
| 798 | |
| 799 | % git remote add avar git://github.com/avar/perl.git |
| 800 | % git fetch avar |
| 801 | |
| 802 | Now you can see the differences between the branch and blead: |
| 803 | |
| 804 | % git diff avar/orange |
| 805 | |
| 806 | And you can see the commits: |
| 807 | |
| 808 | % git log avar/orange |
| 809 | |
| 810 | If you approve of a specific commit, you can cherry pick it: |
| 811 | |
| 812 | % git cherry-pick 0c24b290ae02b2ab3304f51d5e11e85eb3659eae |
| 813 | |
| 814 | Or you could just merge the whole branch if you like it all: |
| 815 | |
| 816 | % git merge avar/orange |
| 817 | |
| 818 | And then push back to the repository: |
| 819 | |
| 820 | % git push origin blead |
| 821 | |
| 822 | =head2 Using a smoke-me branch to test changes |
| 823 | |
| 824 | Sometimes a change affects code paths which you cannot test on the OSes |
| 825 | which are directly available to you and it would be wise to have users |
| 826 | on other OSes test the change before you commit it to blead. |
| 827 | |
| 828 | Fortunately, there is a way to get your change smoke-tested on various |
| 829 | OSes: push it to a "smoke-me" branch and wait for certain automated |
| 830 | smoke-testers to report the results from their OSes. |
| 831 | |
| 832 | The procedure for doing this is roughly as follows (using the example of |
| 833 | of tonyc's smoke-me branch called win32stat): |
| 834 | |
| 835 | First, make a local branch and switch to it: |
| 836 | |
| 837 | % git checkout -b win32stat |
| 838 | |
| 839 | Make some changes, build perl and test your changes, then commit them to |
| 840 | your local branch. Then push your local branch to a remote smoke-me |
| 841 | branch: |
| 842 | |
| 843 | % git push origin win32stat:smoke-me/tonyc/win32stat |
| 844 | |
| 845 | Now you can switch back to blead locally: |
| 846 | |
| 847 | % git checkout blead |
| 848 | |
| 849 | and continue working on other things while you wait a day or two, |
| 850 | keeping an eye on the results reported for your smoke-me branch at |
| 851 | L<http://perl.develop-help.com/?b=smoke-me/tonyc/win32state>. |
| 852 | |
| 853 | If all is well then update your blead branch: |
| 854 | |
| 855 | % git pull |
| 856 | |
| 857 | then checkout your smoke-me branch once more and rebase it on blead: |
| 858 | |
| 859 | % git rebase blead win32stat |
| 860 | |
| 861 | Now switch back to blead and merge your smoke-me branch into it: |
| 862 | |
| 863 | % git checkout blead |
| 864 | % git merge win32stat |
| 865 | |
| 866 | As described earlier, if there are many changes on your smoke-me branch |
| 867 | then you should prepare a merge commit in which to give an overview of |
| 868 | those changes by using the following command instead of the last |
| 869 | command above: |
| 870 | |
| 871 | % git merge win32stat --no-ff --no-commit |
| 872 | |
| 873 | You should now build perl and test your (merged) changes one last time |
| 874 | (ideally run the whole test suite, but failing that at least run the |
| 875 | F<t/porting/*.t> tests) before pushing your changes as usual: |
| 876 | |
| 877 | % git push origin blead |
| 878 | |
| 879 | Finally, you should then delete the remote smoke-me branch: |
| 880 | |
| 881 | % git push origin :smoke-me/tonyc/win32stat |
| 882 | |
| 883 | (which is likely to produce a warning like this, which can be ignored: |
| 884 | |
| 885 | remote: fatal: ambiguous argument 'refs/heads/smoke-me/tonyc/win32stat': |
| 886 | unknown revision or path not in the working tree. |
| 887 | remote: Use '--' to separate paths from revisions |
| 888 | |
| 889 | ) and then delete your local branch: |
| 890 | |
| 891 | % git branch -d win32stat |
| 892 | |
| 893 | =head2 A note on camel and dromedary |
| 894 | |
| 895 | The committers have SSH access to the two servers that serve |
| 896 | C<perl5.git.perl.org>. One is C<perl5.git.perl.org> itself (I<camel>), |
| 897 | which is the 'master' repository. The second one is |
| 898 | C<users.perl5.git.perl.org> (I<dromedary>), which can be used for |
| 899 | general testing and development. Dromedary syncs the git tree from |
| 900 | camel every few minutes, you should not push there. Both machines also |
| 901 | have a full CPAN mirror in /srv/CPAN, please use this. To share files |
| 902 | with the general public, dromedary serves your ~/public_html/ as |
| 903 | C<http://users.perl5.git.perl.org/~yourlogin/> |
| 904 | |
| 905 | These hosts have fairly strict firewalls to the outside. Outgoing, only |
| 906 | rsync, ssh and git are allowed. For http and ftp, you can use |
| 907 | http://webproxy:3128 as proxy. Incoming, the firewall tries to detect |
| 908 | attacks and blocks IP addresses with suspicious activity. This |
| 909 | sometimes (but very rarely) has false positives and you might get |
| 910 | blocked. The quickest way to get unblocked is to notify the admins. |
| 911 | |
| 912 | These two boxes are owned, hosted, and operated by booking.com. You can |
| 913 | reach the sysadmins in #p5p on irc.perl.org or via mail to |
| 914 | C<perl5-porters@perl.org>. |