Commit | Line | Data |
---|---|---|
0549aefb LB |
1 | =for comment |
2 | Consistent formatting of this file is achieved with: | |
3 | perl ./Porting/podtidy pod/perlrepository.pod | |
4 | ||
d7dd28b6 LB |
5 | =head1 NAME |
6 | ||
7 | perlrepository - Using the Perl source repository | |
8 | ||
9 | =head1 SYNOPSIS | |
10 | ||
dc3c3040 | 11 | All of Perl's source code is kept centrally in a Git repository at |
c26da522 LB |
12 | I<perl5.git.perl.org>. The repository contains many Perl revisions from |
13 | Perl 1 onwards and all the revisions from Perforce, the version control | |
14 | system we were using previously. This repository is accessible in | |
15 | different ways. | |
d7dd28b6 LB |
16 | |
17 | The full repository takes up about 80MB of disk space. A check out of | |
7f4ffa9d | 18 | the blead branch (that is, the main development branch, which contains |
6a7cbfe8 LB |
19 | bleadperl, the development version of perl 5) takes up about 160MB of |
20 | disk space (including the repository). A build of bleadperl takes up | |
21 | about 200MB (including the repository and the check out). | |
d7dd28b6 LB |
22 | |
23 | =head1 GETTING ACCESS TO THE REPOSITORY | |
24 | ||
25 | =head2 READ ACCESS VIA THE WEB | |
26 | ||
dc3c3040 GA |
27 | You may access the repository over the web. This allows you to browse |
28 | the tree, see recent commits, subscribe to RSS feeds for the changes, | |
29 | search for particular commits and more. You may access it at: | |
d7dd28b6 LB |
30 | |
31 | http://perl5.git.perl.org/perl.git | |
32 | ||
dc3c3040 GA |
33 | A mirror of the repository is found at: |
34 | ||
35 | http://github.com/github/perl | |
36 | ||
d7dd28b6 LB |
37 | =head2 READ ACCESS VIA GIT |
38 | ||
39 | You will need a copy of Git for your computer. You can fetch a copy of | |
40 | the repository using the Git protocol (which uses port 9418): | |
41 | ||
e0b2b458 | 42 | % git clone git://perl5.git.perl.org/perl.git perl-git |
d7dd28b6 | 43 | |
f755e97d | 44 | This clones the repository and makes a local copy in the F<perl-git> |
d7dd28b6 LB |
45 | directory. |
46 | ||
47 | If your local network does not allow you to use port 9418, then you can | |
cf5e7595 | 48 | fetch a copy of the repository over HTTP (this is at least 4x slower): |
d7dd28b6 | 49 | |
e0b2b458 | 50 | % git clone http://perl5.git.perl.org/perl.git perl-http |
d7dd28b6 | 51 | |
f755e97d | 52 | This clones the repository and makes a local copy in the F<perl-http> |
d7dd28b6 LB |
53 | directory. |
54 | ||
55 | =head2 WRITE ACCESS TO THE REPOSITORY | |
56 | ||
6acba58e LB |
57 | If you are a committer, then you can fetch a copy of the repository |
58 | that you can push back on with: | |
d7dd28b6 | 59 | |
e0b2b458 | 60 | % git clone ssh://perl5.git.perl.org/perl.git perl-ssh |
d7dd28b6 | 61 | |
8f718e95 | 62 | This clones the repository and makes a local copy in the F<perl-ssh> |
d7dd28b6 LB |
63 | directory. |
64 | ||
c26da522 | 65 | If you cloned using the git protocol, which is faster than ssh, then |
11ed6e28 AB |
66 | you will need to modify the URL for the origin remote to enable |
67 | pushing. To do that edit F<.git/config> with L<git-config(1)> like | |
68 | this: | |
1a0f15d5 | 69 | |
e0b2b458 | 70 | % git config remote.origin.url ssh://perl5.git.perl.org/perl.git |
d7dd28b6 | 71 | |
9d77ce3f AB |
72 | You can also set up your user name and e-mail address. Most people do |
73 | this once globally in their F<~/.gitconfig> by doing something like: | |
184487f0 | 74 | |
9d77ce3f AB |
75 | % git config --global user.name "Ævar Arnfjörð Bjarmason" |
76 | % git config --global user.email avarab@gmail.com | |
77 | ||
78 | However if you'd like to override that just for perl then execute then | |
79 | execute something like the following in F<perl-git>: | |
80 | ||
81 | % git config user.email avar@cpan.org | |
184487f0 | 82 | |
6acba58e LB |
83 | It is also possible to keep C<origin> as a git remote, and add a new |
84 | remote for ssh access: | |
f6c12373 | 85 | |
dc3c3040 | 86 | % git remote add camel perl5.git.perl.org:/perl.git |
f6c12373 | 87 | |
6acba58e | 88 | This allows you to update your local repository by pulling from |
f755e97d | 89 | C<origin>, which is faster and doesn't require you to authenticate, and |
6acba58e | 90 | to push your changes back with the C<camel> remote: |
f6c12373 VP |
91 | |
92 | % git fetch camel | |
93 | % git push camel | |
94 | ||
6acba58e LB |
95 | The C<fetch> command just updates the C<camel> refs, as the objects |
96 | themselves should have been fetched when pulling from C<origin>. | |
f6c12373 | 97 | |
3482f01a DK |
98 | =head2 A NOTE ON CAMEL AND DROMEDARY |
99 | ||
100 | The committers have SSH access to the two servers that serve | |
333f8875 VP |
101 | C<perl5.git.perl.org>. One is C<perl5.git.perl.org> itself (I<camel>), |
102 | which is the 'master' repository. The second one is | |
103 | C<users.perl5.git.perl.org> (I<dromedary>), which can be used for | |
104 | general testing and development. Dromedary syncs the git tree from | |
105 | camel every few minutes, you should not push there. Both machines also | |
3482f01a DK |
106 | have a full CPAN mirror in /srv/CPAN, please use this. To share files |
107 | with the general public, dromedary serves your ~/public_html/ as | |
333f8875 | 108 | C<http://users.perl5.git.perl.org/~yourlogin/> |
b47aa495 | 109 | |
3482f01a DK |
110 | These hosts have fairly strict firewalls to the outside. Outgoing, only |
111 | rsync, ssh and git are allowed. For http and ftp, you can use | |
112 | http://webproxy:3128 as proxy. Incoming, the firewall tries to detect | |
113 | attacks and blocks IP addresses with suspicious activity. This | |
114 | sometimes (but very rarely) has false positives and you might get | |
115 | blocked. The quickest way to get unblocked is to notify the admins. | |
116 | ||
117 | These two boxes are owned, hosted, and operated by booking.com. You can | |
118 | reach the sysadmins in #p5p on irc.perl.org or via mail to | |
119 | C<perl5-porters@perl.org> | |
120 | ||
d7dd28b6 LB |
121 | =head1 OVERVIEW OF THE REPOSITORY |
122 | ||
6acba58e LB |
123 | Once you have changed into the repository directory, you can inspect |
124 | it. | |
d7dd28b6 | 125 | |
39219fd3 | 126 | After a clone the repository will contain a single local branch, which |
50eca761 | 127 | will be the current branch as well, as indicated by the asterisk. |
39219fd3 YO |
128 | |
129 | % git branch | |
130 | * blead | |
131 | ||
f755e97d | 132 | Using the -a switch to C<branch> will also show the remote tracking |
6acba58e | 133 | branches in the repository: |
39219fd3 | 134 | |
d9847473 | 135 | % git branch -a |
09081495 | 136 | * blead |
d7dd28b6 LB |
137 | origin/HEAD |
138 | origin/blead | |
139 | ... | |
140 | ||
6acba58e LB |
141 | The branches that begin with "origin" correspond to the "git remote" |
142 | that you cloned from (which is named "origin"). Each branch on the | |
143 | remote will be exactly tracked by theses branches. You should NEVER do | |
144 | work on these remote tracking branches. You only ever do work in a | |
145 | local branch. Local branches can be configured to automerge (on pull) | |
146 | from a designated remote tracking branch. This is the case with the | |
147 | default branch C<blead> which will be configured to merge from the | |
148 | remote tracking branch C<origin/blead>. | |
39219fd3 | 149 | |
d7dd28b6 LB |
150 | You can see recent commits: |
151 | ||
c2cf2042 | 152 | % git log |
d7dd28b6 | 153 | |
6acba58e LB |
154 | And pull new changes from the repository, and update your local |
155 | repository (must be clean first) | |
d7dd28b6 LB |
156 | |
157 | % git pull | |
09081495 | 158 | |
6acba58e LB |
159 | Assuming we are on the branch C<blead> immediately after a pull, this |
160 | command would be more or less equivalent to: | |
39219fd3 YO |
161 | |
162 | % git fetch | |
163 | % git merge origin/blead | |
164 | ||
6acba58e LB |
165 | In fact if you want to update your local repository without touching |
166 | your working directory you do: | |
39219fd3 YO |
167 | |
168 | % git fetch | |
169 | ||
6acba58e LB |
170 | And if you want to update your remote-tracking branches for all defined |
171 | remotes simultaneously you can do | |
39219fd3 YO |
172 | |
173 | % git remote update | |
174 | ||
6acba58e LB |
175 | Neither of these last two commands will update your working directory, |
176 | however both will update the remote-tracking branches in your | |
177 | repository. | |
39219fd3 | 178 | |
09081495 LB |
179 | To switch to another branch: |
180 | ||
181 | % git checkout origin/maint-5.8-dor | |
182 | ||
6051489b NC |
183 | To make a local branch of a remote branch: |
184 | ||
185 | % git checkout -b maint-5.10 origin/maint-5.10 | |
186 | ||
09081495 LB |
187 | To switch back to blead: |
188 | ||
189 | % git checkout blead | |
c2cf2042 | 190 | |
39219fd3 YO |
191 | =head2 FINDING OUT YOUR STATUS |
192 | ||
193 | The most common git command you will use will probably be | |
194 | ||
195 | % git status | |
196 | ||
6acba58e LB |
197 | This command will produce as output a description of the current state |
198 | of the repository, including modified files and unignored untracked | |
199 | files, and in addition it will show things like what files have been | |
200 | staged for the next commit, and usually some useful information about | |
201 | how to change things. For instance the following: | |
39219fd3 YO |
202 | |
203 | $ git status | |
204 | # On branch blead | |
205 | # Your branch is ahead of 'origin/blead' by 1 commit. | |
206 | # | |
207 | # Changes to be committed: | |
208 | # (use "git reset HEAD <file>..." to unstage) | |
209 | # | |
210 | # modified: pod/perlrepository.pod | |
211 | # | |
212 | # Changed but not updated: | |
213 | # (use "git add <file>..." to update what will be committed) | |
214 | # | |
215 | # modified: pod/perlrepository.pod | |
216 | # | |
217 | # Untracked files: | |
218 | # (use "git add <file>..." to include in what will be committed) | |
219 | # | |
220 | # deliberate.untracked | |
221 | ||
6acba58e LB |
222 | This shows that there were changes to this document staged for commit, |
223 | and that there were further changes in the working directory not yet | |
224 | staged. It also shows that there was an untracked file in the working | |
225 | directory, and as you can see shows how to change all of this. It also | |
0549aefb LB |
226 | shows that there is one commit on the working branch C<blead> which has |
227 | not been pushed to the C<origin> remote yet. B<NOTE>: that this output | |
228 | is also what you see as a template if you do not provide a message to | |
229 | C<git commit>. | |
7f6effc7 | 230 | |
bdaf0bc6 JV |
231 | Assuming that you'd like to commit all the changes you've just made as a |
232 | a single atomic unit, run this command: | |
233 | ||
234 | % git commit -a | |
235 | ||
236 | (That C<-a> tells git to add every file you've changed to this commit. | |
ea9c0d74 JV |
237 | New files aren't automatically added to your commit when you use C<commit |
238 | -a> If you want to add files or to commit some, but not all of your | |
239 | changes, have a look at the documentation for C<git add>.) | |
bdaf0bc6 | 240 | |
e9360695 | 241 | Git will start up your favorite text editor, so that you can craft a |
bdaf0bc6 JV |
242 | commit message for your change. See L</Commit message> below for more |
243 | information about what makes a good commit message. | |
244 | ||
245 | Once you've finished writing your commit message and exited your editor, | |
246 | git will write your change to disk and tell you something like this: | |
7f6effc7 | 247 | |
7f6effc7 YO |
248 | Created commit daf8e63: explain git status and stuff about remotes |
249 | 1 files changed, 83 insertions(+), 3 deletions(-) | |
250 | ||
bdaf0bc6 JV |
251 | |
252 | If you re-run C<git status>, you should see something like this: | |
7f6effc7 YO |
253 | |
254 | % git status | |
255 | # On branch blead | |
256 | # Your branch is ahead of 'origin/blead' by 2 commits. | |
257 | # | |
258 | # Untracked files: | |
259 | # (use "git add <file>..." to include in what will be committed) | |
260 | # | |
261 | # deliberate.untracked | |
262 | nothing added to commit but untracked files present (use "git add" to track) | |
263 | ||
39219fd3 | 264 | |
6acba58e LB |
265 | When in doubt, before you do anything else, check your status and read |
266 | it carefully, many questions are answered directly by the git status | |
267 | output. | |
39219fd3 | 268 | |
c2cf2042 LB |
269 | =head1 SUBMITTING A PATCH |
270 | ||
271 | If you have a patch in mind for Perl, you should first get a copy of | |
272 | the repository: | |
273 | ||
274 | % git clone git://perl5.git.perl.org/perl.git perl-git | |
275 | ||
276 | Then change into the directory: | |
277 | ||
278 | % cd perl-git | |
279 | ||
6acba58e LB |
280 | Alternatively, if you already have a Perl repository, you should ensure |
281 | that you're on the I<blead> branch, and your repository is up to date: | |
12322d22 A |
282 | |
283 | % git checkout blead | |
284 | % git pull | |
285 | ||
6a7cbfe8 LB |
286 | It's preferable to patch against the latest blead version, since this |
287 | is where new development occurs for all changes other than critical bug | |
288 | fixes. Critical bug fix patches should be made against the relevant | |
7f4ffa9d RS |
289 | maint branches, or should be submitted with a note indicating all the |
290 | branches where the fix should be applied. | |
a44f43ac | 291 | |
6acba58e LB |
292 | Now that we have everything up to date, we need to create a temporary |
293 | new branch for these changes and switch into it: | |
b1fccde5 | 294 | |
a9b05323 | 295 | % git checkout -b orange |
23f8d33e | 296 | |
a9b05323 YO |
297 | which is the short form of |
298 | ||
b1fccde5 LB |
299 | % git branch orange |
300 | % git checkout orange | |
301 | ||
0c24b290 AB |
302 | Creating a topic branch makes it easier for the maintainers to rebase |
303 | or merge back into the master blead for a more linear history. If you | |
304 | don't work on a topic branch the maintainer has to manually cherry | |
305 | pick your changes onto blead before they can be applied. | |
306 | ||
307 | That'll get you scolded on perl5-porters, so don't do that. Be | |
308 | Awesome. | |
309 | ||
c2cf2042 LB |
310 | Then make your changes. For example, if Leon Brocard changes his name |
311 | to Orange Brocard, we should change his name in the AUTHORS file: | |
312 | ||
313 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS | |
314 | ||
315 | You can see what files are changed: | |
316 | ||
317 | % git status | |
f755e97d | 318 | # On branch orange |
c2cf2042 LB |
319 | # Changes to be committed: |
320 | # (use "git reset HEAD <file>..." to unstage) | |
321 | # | |
2699d634 | 322 | # modified: AUTHORS |
c2cf2042 LB |
323 | # |
324 | ||
c2cf2042 LB |
325 | And you can see the changes: |
326 | ||
327 | % git diff | |
328 | diff --git a/AUTHORS b/AUTHORS | |
329 | index 293dd70..722c93e 100644 | |
330 | --- a/AUTHORS | |
331 | +++ b/AUTHORS | |
7df2e4bc | 332 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
c2cf2042 LB |
333 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
334 | Leif Huhn <leif@hale.dkstat.com> | |
335 | Len Johnson <lenjay@ibm.net> | |
336 | -Leon Brocard <acme@astray.com> | |
337 | +Orange Brocard <acme@astray.com> | |
338 | Les Peters <lpeters@aol.net> | |
339 | Lesley Binks <lesley.binks@gmail.com> | |
340 | Lincoln D. Stein <lstein@cshl.org> | |
341 | ||
342 | Now commit your change locally: | |
343 | ||
dc3c3040 | 344 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
c2cf2042 LB |
345 | Created commit 6196c1d: Rename Leon Brocard to Orange Brocard |
346 | 1 files changed, 1 insertions(+), 1 deletions(-) | |
347 | ||
dc3c3040 GA |
348 | You can examine your last commit with: |
349 | ||
350 | % git show HEAD | |
351 | ||
352 | and if you are not happy with either the description or the patch | |
c26da522 | 353 | itself you can fix it up by editing the files once more and then issue: |
dc3c3040 GA |
354 | |
355 | % git commit -a --amend | |
356 | ||
c2cf2042 LB |
357 | Now you should create a patch file for all your local changes: |
358 | ||
2af192ee | 359 | % git format-patch origin |
c2cf2042 LB |
360 | 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
361 | ||
362 | You should now send an email to perl5-porters@perl.org with a | |
dc3c3040 | 363 | description of your changes, and include this patch file as an |
333f8875 VP |
364 | attachment. (See the next section for how to configure and use git to |
365 | send these emails for you.) | |
c2cf2042 | 366 | |
b1fccde5 LB |
367 | If you want to delete your temporary branch, you may do so with: |
368 | ||
369 | % git checkout blead | |
370 | % git branch -d orange | |
371 | error: The branch 'orange' is not an ancestor of your current HEAD. | |
372 | If you are sure you want to delete it, run 'git branch -D orange'. | |
373 | % git branch -D orange | |
374 | Deleted branch orange. | |
7df2e4bc | 375 | |
2d5f1d01 DG |
376 | =head2 Using git to send patch emails |
377 | ||
333f8875 VP |
378 | In your ~/git/perl repository, set the destination email to the |
379 | perl5-porters mailing list. | |
2d5f1d01 DG |
380 | |
381 | $ git config sendemail.to perl5-porters@perl.org | |
382 | ||
383 | Then you can use git directly to send your patch emails: | |
384 | ||
385 | $ git send-email 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch | |
386 | ||
333f8875 VP |
387 | You may need to set some configuration variables for your particular |
388 | email service provider. For example, to set your global git config to | |
389 | send email via a gmail account: | |
2d5f1d01 DG |
390 | |
391 | $ git config --global sendemail.smtpserver smtp.gmail.com | |
392 | $ git config --global sendemail.smtpssl 1 | |
393 | $ git config --global sendemail.smtpuser YOURUSERNAME@gmail.com | |
394 | ||
333f8875 VP |
395 | With this configuration, you will be prompted for your gmail password |
396 | when you run 'git send-email'. You can also configure | |
397 | C<sendemail.smtppass> with your password if you don't care about having | |
398 | your password in the .gitconfig file. | |
2d5f1d01 | 399 | |
a44f43ac RGS |
400 | =head2 A note on derived files |
401 | ||
402 | Be aware that many files in the distribution are derivative--avoid | |
0549aefb LB |
403 | patching them, because git won't see the changes to them, and the build |
404 | process will overwrite them. Patch the originals instead. Most | |
405 | utilities (like perldoc) are in this category, i.e. patch | |
406 | utils/perldoc.PL rather than utils/perldoc. Similarly, don't create | |
407 | patches for files under $src_root/ext from their copies found in | |
408 | $install_root/lib. If you are unsure about the proper location of a | |
409 | file that may have gotten copied while building the source | |
410 | distribution, consult the C<MANIFEST>. | |
a44f43ac | 411 | |
ac1cbfb0 JC |
412 | As a special case, several files are regenerated by 'make regen' if |
413 | your patch alters C<embed.fnc>. These are needed for compilation, but | |
414 | are included in the distribution so that you can build perl without | |
415 | needing another perl to generate the files. You must test with these | |
416 | regenerated files, but it is preferred that you instead note that | |
417 | 'make regen is needed' in both the email and the commit message, and | |
418 | submit your patch without them. If you're submitting a series of | |
419 | patches, it might be best to submit the regenerated changes | |
420 | immediately after the source-changes that caused them, so as to have | |
421 | as little effect as possible on the bisectability of your patchset. | |
422 | ||
6e2cec71 | 423 | =for XXX |
a44f43ac | 424 | |
6e2cec71 | 425 | What should we recommend about binary files now? Do we need anything? |
a44f43ac RGS |
426 | |
427 | =head2 Getting your patch accepted | |
428 | ||
bdaf0bc6 | 429 | If you are submitting a code patch there are several things that |
a44f43ac RGS |
430 | you need to do. |
431 | ||
432 | =over 4 | |
433 | ||
bdaf0bc6 JV |
434 | =item Commit message |
435 | ||
436 | As you craft each patch you intend to submit to the Perl core, it's | |
437 | important to write a good commit message. | |
438 | ||
439 | Your commit message should start with a description of the problem that | |
440 | the patch corrects or new functionality that the patch adds. | |
441 | ||
bdaf0bc6 JV |
442 | As a general rule of thumb, your commit message should let a programmer |
443 | with a reasonable familiarity with the Perl core quickly understand what | |
444 | you were trying to do, how you were trying to do it and why the change | |
445 | matters to Perl. | |
446 | ||
447 | =over 4 | |
448 | ||
449 | =item What | |
450 | ||
ac1cbfb0 JC |
451 | Your commit message should describe what part of the Perl core you're |
452 | changing and what you expect your patch to do. | |
bdaf0bc6 JV |
453 | |
454 | =item Why | |
455 | ||
456 | Perhaps most importantly, your commit message should describe why the | |
457 | change you are making is important. When someone looks at your change | |
458 | in six months or six years, your intent should be clear. If you're | |
459 | deprecating a feature with the intent of later simplifying another bit | |
460 | of code, say so. If you're fixing a performance problem or adding a new | |
461 | feature to support some other bit of the core, mention that. | |
462 | ||
463 | =item How | |
464 | ||
465 | While it's not necessary for documentation changes, new tests or | |
466 | trivial patches, it's often worth explaining how your change works. | |
467 | Even if it's clear to you today, it may not be clear to a porter next | |
468 | month or next year. | |
469 | ||
470 | =back | |
471 | ||
ea9c0d74 JV |
472 | A commit message isn't intended to take the place of comments in your |
473 | code. Commit messages should describe the change you made, while code | |
80a0006a JV |
474 | comments should describe the current state of the code. If you've just |
475 | implemented a new feature, complete with doc, tests and well-commented | |
476 | code, a brief commit message will often suffice. If, however, you've | |
477 | just changed a single character deep in the parser or lexer, you might | |
ea9c0d74 JV |
478 | need to write a small novel to ensure that future readers understand |
479 | what you did and why you did it. | |
480 | ||
a44f43ac RGS |
481 | =item Comments, Comments, Comments |
482 | ||
0549aefb LB |
483 | Be sure to adequately comment your code. While commenting every line |
484 | is unnecessary, anything that takes advantage of side effects of | |
a44f43ac | 485 | operators, that creates changes that will be felt outside of the |
0549aefb LB |
486 | function being patched, or that others may find confusing should be |
487 | documented. If you are going to err, it is better to err on the side | |
488 | of adding too many comments than too few. | |
a44f43ac RGS |
489 | |
490 | =item Style | |
491 | ||
0549aefb LB |
492 | In general, please follow the particular style of the code you are |
493 | patching. | |
a44f43ac | 494 | |
0549aefb LB |
495 | In particular, follow these general guidelines for patching Perl |
496 | sources: | |
a44f43ac RGS |
497 | |
498 | 8-wide tabs (no exceptions!) | |
499 | 4-wide indents for code, 2-wide indents for nested CPP #defines | |
500 | try hard not to exceed 79-columns | |
501 | ANSI C prototypes | |
502 | uncuddled elses and "K&R" style for indenting control constructs | |
503 | no C++ style (//) comments | |
504 | mark places that need to be revisited with XXX (and revisit often!) | |
505 | opening brace lines up with "if" when conditional spans multiple | |
506 | lines; should be at end-of-line otherwise | |
507 | in function definitions, name starts in column 0 (return value is on | |
508 | previous line) | |
509 | single space after keywords that are followed by parens, no space | |
510 | between function name and following paren | |
511 | avoid assignments in conditionals, but if they're unavoidable, use | |
512 | extra paren, e.g. "if (a && (b = c)) ..." | |
513 | "return foo;" rather than "return(foo);" | |
514 | "if (!foo) ..." rather than "if (foo == FALSE) ..." etc. | |
515 | ||
516 | =item Testsuite | |
517 | ||
bdaf0bc6 JV |
518 | If your patch changes code (rather than just changing documentation) you |
519 | should also include one or more test cases which illustrate the bug you're | |
520 | fixing or validate the new functionality you're adding. In general, | |
521 | you should update an existing test file rather than create a new one. | |
522 | ||
0549aefb LB |
523 | Your testsuite additions should generally follow these guidelines |
524 | (courtesy of Gurusamy Sarathy <gsar@activestate.com>): | |
a44f43ac RGS |
525 | |
526 | Know what you're testing. Read the docs, and the source. | |
527 | Tend to fail, not succeed. | |
528 | Interpret results strictly. | |
529 | Use unrelated features (this will flush out bizarre interactions). | |
530 | Use non-standard idioms (otherwise you are not testing TIMTOWTDI). | |
531 | Avoid using hardcoded test numbers whenever possible (the | |
532 | EXPECTED/GOT found in t/op/tie.t is much more maintainable, | |
533 | and gives better failure reports). | |
534 | Give meaningful error messages when a test fails. | |
535 | Avoid using qx// and system() unless you are testing for them. If you | |
536 | do use them, make sure that you cover _all_ perl platforms. | |
537 | Unlink any temporary files you create. | |
538 | Promote unforeseen warnings to errors with $SIG{__WARN__}. | |
539 | Be sure to use the libraries and modules shipped with the version | |
540 | being tested, not those that were already installed. | |
541 | Add comments to the code explaining what you are testing for. | |
542 | Make updating the '1..42' string unnecessary. Or make sure that | |
543 | you update it. | |
544 | Test _all_ behaviors of a given operator, library, or function: | |
545 | - All optional arguments | |
546 | - Return values in various contexts (boolean, scalar, list, lvalue) | |
547 | - Use both global and lexical variables | |
548 | - Don't forget the exceptional, pathological cases. | |
549 | ||
550 | =back | |
551 | ||
7df2e4bc LB |
552 | =head1 ACCEPTING A PATCH |
553 | ||
554 | If you have received a patch file generated using the above section, | |
555 | you should try out the patch. | |
556 | ||
557 | First we need to create a temporary new branch for these changes and | |
558 | switch into it: | |
559 | ||
a9b05323 | 560 | % git checkout -b experimental |
7df2e4bc | 561 | |
6acba58e LB |
562 | Patches that were formatted by C<git format-patch> are applied with |
563 | C<git am>: | |
7df2e4bc | 564 | |
2af192ee | 565 | % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
7df2e4bc LB |
566 | Applying Rename Leon Brocard to Orange Brocard |
567 | ||
6acba58e LB |
568 | If just a raw diff is provided, it is also possible use this two-step |
569 | process: | |
09645c26 VP |
570 | |
571 | % git apply bugfix.diff | |
dc3c3040 | 572 | % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>" |
09645c26 | 573 | |
7df2e4bc LB |
574 | Now we can inspect the change: |
575 | ||
dc3c3040 | 576 | % git show HEAD |
7df2e4bc LB |
577 | commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 |
578 | Author: Leon Brocard <acme@astray.com> | |
579 | Date: Fri Dec 19 17:02:59 2008 +0000 | |
580 | ||
581 | Rename Leon Brocard to Orange Brocard | |
7df2e4bc | 582 | |
7df2e4bc LB |
583 | diff --git a/AUTHORS b/AUTHORS |
584 | index 293dd70..722c93e 100644 | |
585 | --- a/AUTHORS | |
586 | +++ b/AUTHORS | |
587 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> | |
588 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> | |
589 | Leif Huhn <leif@hale.dkstat.com> | |
590 | Len Johnson <lenjay@ibm.net> | |
591 | -Leon Brocard <acme@astray.com> | |
592 | +Orange Brocard <acme@astray.com> | |
593 | Les Peters <lpeters@aol.net> | |
594 | Lesley Binks <lesley.binks@gmail.com> | |
595 | Lincoln D. Stein <lstein@cshl.org> | |
596 | ||
597 | If you are a committer to Perl and you think the patch is good, you can | |
75fb7651 | 598 | then merge it into blead then push it out to the main repository: |
7df2e4bc LB |
599 | |
600 | % git checkout blead | |
d9847473 | 601 | % git merge experimental |
75fb7651 | 602 | % git push |
7df2e4bc LB |
603 | |
604 | If you want to delete your temporary branch, you may do so with: | |
605 | ||
606 | % git checkout blead | |
607 | % git branch -d experimental | |
608 | error: The branch 'experimental' is not an ancestor of your current HEAD. | |
609 | If you are sure you want to delete it, run 'git branch -D experimental'. | |
610 | % git branch -D experimental | |
611 | Deleted branch experimental. | |
b0d36535 YO |
612 | |
613 | =head1 CLEANING A WORKING DIRECTORY | |
614 | ||
6acba58e | 615 | The command C<git clean> can with varying arguments be used as a |
dc3c3040 | 616 | replacement for C<make clean>. |
b0d36535 YO |
617 | |
618 | To reset your working directory to a pristine condition you can do: | |
619 | ||
e0b2b458 | 620 | % git clean -dxf |
b0d36535 YO |
621 | |
622 | However, be aware this will delete ALL untracked content. You can use | |
623 | ||
e0b2b458 | 624 | % git clean -Xf |
b0d36535 | 625 | |
6acba58e LB |
626 | to remove all ignored untracked files, such as build and test |
627 | byproduct, but leave any manually created files alone. | |
b0d36535 | 628 | |
0549aefb | 629 | If you only want to cancel some uncommitted edits, you can use C<git |
c26da522 LB |
630 | checkout> and give it a list of files to be reverted, or C<git checkout |
631 | -f> to revert them all. | |
f755e97d RGS |
632 | |
633 | If you want to cancel one or several commits, you can use C<git reset>. | |
634 | ||
d82a90c1 VP |
635 | =head1 BISECTING |
636 | ||
6acba58e LB |
637 | C<git> provides a built-in way to determine, with a binary search in |
638 | the history, which commit should be blamed for introducing a given bug. | |
d82a90c1 | 639 | |
6acba58e | 640 | Suppose that we have a script F<~/testcase.pl> that exits with C<0> |
bdaf0bc6 | 641 | when some behaviour is correct, and with C<1> when it's faulty. You need |
6acba58e LB |
642 | an helper script that automates building C<perl> and running the |
643 | testcase: | |
d82a90c1 VP |
644 | |
645 | % cat ~/run | |
646 | #!/bin/sh | |
647 | git clean -dxf | |
648 | # If you can use ccache, add -Dcc=ccache\ gcc -Dld=gcc to the Configure line | |
1d5fe431 MB |
649 | # if Encode is not needed for the test, you can speed up the bisect by |
650 | # excluding it from the runs with -Dnoextensions=Encode | |
c0d1ef72 MB |
651 | sh Configure -des -Dusedevel -Doptimize="-g" |
652 | test -f config.sh || exit 125 | |
653 | # Correct makefile for newer GNU gcc | |
654 | perl -ni -we 'print unless /<(?:built-in|command)/' makefile x2p/makefile | |
655 | # if you just need miniperl, replace test_prep with miniperl | |
656 | make -j4 test_prep | |
68814ba4 | 657 | [ -x ./perl ] || exit 125 |
d82a90c1 | 658 | ./perl -Ilib ~/testcase.pl |
c0d1ef72 | 659 | ret=$? |
7930c68b | 660 | [ $ret -gt 127 ] && ret=127 |
c0d1ef72 MB |
661 | git clean -dxf |
662 | exit $ret | |
d82a90c1 | 663 | |
6acba58e LB |
664 | This script may return C<125> to indicate that the corresponding commit |
665 | should be skipped. Otherwise, it returns the status of | |
666 | F<~/testcase.pl>. | |
d82a90c1 | 667 | |
bdaf0bc6 | 668 | You first enter in bisect mode with: |
d82a90c1 VP |
669 | |
670 | % git bisect start | |
671 | ||
6acba58e LB |
672 | For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, |
673 | C<git> will learn about this when you enter: | |
d82a90c1 VP |
674 | |
675 | % git bisect bad | |
676 | % git bisect good perl-5.10.0 | |
677 | Bisecting: 853 revisions left to test after this | |
678 | ||
6acba58e | 679 | This results in checking out the median commit between C<HEAD> and |
bdaf0bc6 | 680 | C<perl-5.10.0>. You can then run the bisecting process with: |
d82a90c1 VP |
681 | |
682 | % git bisect run ~/run | |
683 | ||
684 | When the first bad commit is isolated, C<git bisect> will tell you so: | |
685 | ||
686 | ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit | |
687 | commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 | |
688 | Author: Dave Mitchell <davem@fdisolutions.com> | |
689 | Date: Sat Feb 9 14:56:23 2008 +0000 | |
690 | ||
9469eb4a | 691 | [perl #49472] Attributes + Unknown Error |
d82a90c1 VP |
692 | ... |
693 | ||
694 | bisect run success | |
695 | ||
6acba58e LB |
696 | You can peek into the bisecting process with C<git bisect log> and |
697 | C<git bisect visualize>. C<git bisect reset> will get you out of bisect | |
698 | mode. | |
d82a90c1 | 699 | |
6acba58e LB |
700 | Please note that the first C<good> state must be an ancestor of the |
701 | first C<bad> state. If you want to search for the commit that I<solved> | |
702 | some bug, you have to negate your test case (i.e. exit with C<1> if OK | |
703 | and C<0> if not) and still mark the lower bound as C<good> and the | |
704 | upper as C<bad>. The "first bad commit" has then to be understood as | |
705 | the "first commit where the bug is solved". | |
d82a90c1 | 706 | |
6acba58e LB |
707 | C<git help bisect> has much more information on how you can tweak your |
708 | binary searches. | |
9d68b7ed | 709 | |
03050721 LB |
710 | =head1 SUBMITTING A PATCH VIA GITHUB |
711 | ||
712 | GitHub is a website that makes it easy to fork and publish projects | |
713 | with Git. First you should set up a GitHub account and log in. | |
714 | ||
715 | Perl's git repository is mirrored on GitHub at this page: | |
716 | ||
717 | http://github.com/github/perl/tree/blead | |
718 | ||
719 | Visit the page and click the "fork" button. This clones the Perl git | |
720 | repository for you and provides you with "Your Clone URL" from which | |
721 | you should clone: | |
722 | ||
723 | % git clone git@github.com:USERNAME/perl.git perl-github | |
724 | ||
bdaf0bc6 | 725 | The same patch as above, using github might look like this: |
03050721 LB |
726 | |
727 | % cd perl-github | |
728 | % git remote add upstream git://github.com/github/perl.git | |
729 | % git pull upstream blead | |
730 | % git checkout -b orange | |
731 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS | |
dc3c3040 | 732 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
03050721 LB |
733 | % git push origin orange |
734 | ||
735 | The orange branch has been pushed to GitHub, so you should now send an | |
736 | email to perl5-porters@perl.org with a description of your changes and | |
737 | the following information: | |
738 | ||
739 | http://github.com/USERNAME/perl/tree/orange | |
740 | git@github.com:USERNAME/perl.git branch orange | |
741 | ||
c26da522 LB |
742 | =head1 MERGING FROM A BRANCH VIA GITHUB |
743 | ||
744 | If someone has provided a branch via GitHub and you are a committer, | |
5c9c28c6 | 745 | you should use the following in your perl-ssh directory: |
c26da522 LB |
746 | |
747 | % git remote add dandv git://github.com/dandv/perl.git | |
fe442cc0 | 748 | % git fetch dandv |
c26da522 LB |
749 | |
750 | Now you can see the differences between the branch and blead: | |
751 | ||
752 | % git diff dandv/blead | |
753 | ||
754 | And you can see the commits: | |
755 | ||
756 | % git log dandv/blead | |
757 | ||
758 | If you approve of a specific commit, you can cherry pick it: | |
759 | ||
2bab0636 LB |
760 | % git cherry-pick 3adac458cb1c1d41af47fc66e67b49c8dec2323f |
761 | ||
762 | Or you could just merge the whole branch if you like it all: | |
763 | ||
764 | % git merge dandv/blead | |
c26da522 LB |
765 | |
766 | And then push back to the repository: | |
767 | ||
768 | % git push | |
769 | ||
ce2a8773 JV |
770 | |
771 | =head1 TOPIC BRANCHES AND REWRITING HISTORY | |
772 | ||
773 | Individual committers should create topic branches under | |
333f8875 VP |
774 | B<yourname>/B<some_descriptive_name>. Other committers should check |
775 | with a topic branch's creator before making any change to it. | |
ce2a8773 | 776 | |
b16add97 AP |
777 | The simplest way to create a remote topic branch that works on all |
778 | versions of git is to push the current head as a new branch on the | |
779 | remote, then check it out locally: | |
780 | ||
781 | $ branch="$yourname/$some_descriptive_name" | |
782 | $ git push origin HEAD:$branch | |
783 | $ git checkout -b $branch origin/$branch | |
784 | ||
785 | Users of git 1.7 or newer can do it in a more obvious manner: | |
786 | ||
787 | $ branch="$yourname/$some_descriptive_name" | |
788 | $ git checkout -b $branch | |
789 | $ git push origin -u $branch | |
33e5002f | 790 | |
ce2a8773 JV |
791 | If you are not the creator of B<yourname>/B<some_descriptive_name>, you |
792 | might sometimes find that the original author has edited the branch's | |
793 | history. There are lots of good reasons for this. Sometimes, an author | |
333f8875 VP |
794 | might simply be rebasing the branch onto a newer source point. |
795 | Sometimes, an author might have found an error in an early commit which | |
796 | they wanted to fix before merging the branch to blead. | |
ce2a8773 | 797 | |
333f8875 VP |
798 | Currently the master repository is configured to forbid |
799 | non-fast-forward merges. This means that the branches within can not | |
800 | be rebased and pushed as a single step. | |
ce2a8773 | 801 | |
333f8875 VP |
802 | The only way you will ever be allowed to rebase or modify the history |
803 | of a pushed branch is to delete it and push it as a new branch under | |
804 | the same name. Please think carefully about doing this. It may be | |
805 | better to sequentially rename your branches so that it is easier for | |
806 | others working with you to cherry-pick their local changes onto the new | |
807 | version. (XXX: needs explanation). | |
ce2a8773 JV |
808 | |
809 | If you want to rebase a personal topic branch, you will have to delete | |
2699d634 YO |
810 | your existing topic branch and push as a new version of it. You can do |
811 | this via the following formula (see the explanation about C<refspec>'s | |
812 | in the git push documentation for details) after you have rebased your | |
813 | branch: | |
814 | ||
815 | # first rebase | |
816 | $ git checkout $user/$topic | |
817 | $ git fetch | |
818 | $ git rebase origin/blead | |
819 | ||
820 | # then "delete-and-push" | |
821 | $ git push origin :$user/$topic | |
822 | $ git push origin $user/$topic | |
823 | ||
824 | B<NOTE:> it is forbidden at the repository level to delete any of the | |
333f8875 VP |
825 | "primary" branches. That is any branch matching |
826 | C<m!^(blead|maint|perl)!>. Any attempt to do so will result in git | |
827 | producing an error like this: | |
2699d634 YO |
828 | |
829 | $ git push origin :blead | |
830 | *** It is forbidden to delete blead/maint branches in this repository | |
831 | error: hooks/update exited with error code 1 | |
832 | error: hook declined to update refs/heads/blead | |
333f8875 | 833 | To ssh://perl5.git.perl.org/perl |
2699d634 | 834 | ! [remote rejected] blead (hook declined) |
333f8875 | 835 | error: failed to push some refs to 'ssh://perl5.git.perl.org/perl' |
2699d634 | 836 | |
333f8875 VP |
837 | As a matter of policy we do B<not> edit the history of the blead and |
838 | maint-* branches. If a typo (or worse) sneaks into a commit to blead or | |
839 | maint-*, we'll fix it in another commit. The only types of updates | |
840 | allowed on these branches are "fast-forward's", where all history is | |
841 | preserved. | |
2699d634 | 842 | |
333f8875 VP |
843 | Annotated tags in the canonical perl.git repository will never be |
844 | deleted or modified. Think long and hard about whether you want to push | |
845 | a local tag to perl.git before doing so. (Pushing unannotated tags is | |
2699d634 | 846 | not allowed.) |
ce2a8773 | 847 | |
9469eb4a | 848 | =head1 COMMITTING TO MAINTENANCE VERSIONS |
9d68b7ed | 849 | |
7f4ffa9d RS |
850 | Maintenance versions should only be altered to add critical bug fixes. |
851 | ||
9d68b7ed LB |
852 | To commit to a maintenance version of perl, you need to create a local |
853 | tracking branch: | |
854 | ||
855 | % git checkout --track -b maint-5.005 origin/maint-5.005 | |
856 | ||
0549aefb LB |
857 | This creates a local branch named C<maint-5.005>, which tracks the |
858 | remote branch C<origin/maint-5.005>. Then you can pull, commit, merge | |
859 | and push as before. | |
b0d36535 | 860 | |
f755e97d | 861 | You can also cherry-pick commits from blead and another branch, by |
0549aefb LB |
862 | using the C<git cherry-pick> command. It is recommended to use the |
863 | B<-x> option to C<git cherry-pick> in order to record the SHA1 of the | |
864 | original commit in the new commit message. | |
f755e97d | 865 | |
e8589bfa AV |
866 | =head1 GRAFTS |
867 | ||
868 | The perl history contains one mistake which was not caught in the | |
ac036724 | 869 | conversion: a merge was recorded in the history between blead and |
333f8875 VP |
870 | maint-5.10 where no merge actually occurred. Due to the nature of git, |
871 | this is now impossible to fix in the public repository. You can remove | |
872 | this mis-merge locally by adding the following line to your | |
e8589bfa AV |
873 | C<.git/info/grafts> file: |
874 | ||
875 | 296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930 | |
876 | ||
877 | It is particularly important to have this graft line if any bisecting | |
878 | is done in the area of the "merge" in question. | |
879 | ||
bdaf0bc6 JV |
880 | |
881 | ||
f755e97d RGS |
882 | =head1 SEE ALSO |
883 | ||
884 | The git documentation, accessible via C<git help command>. | |
0549aefb | 885 |