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 | ||
3b8a5fb0 | 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 | |
572f57ba | 48 | fetch a copy of the repository over HTTP (this is slower): |
d7dd28b6 | 49 | |
3b8a5fb0 | 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 | |
3b8a5fb0 | 60 | git clone ssh://perl5.git.perl.org/gitroot/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 LB |
65 | If you cloned using the git protocol, which is faster than ssh, then |
66 | you will need to modify your config in order to enable pushing. Edit | |
67 | F<.git/config> where you will see something like: | |
1a0f15d5 YO |
68 | |
69 | [remote "origin"] | |
70 | url = git://perl5.git.perl.org/perl.git | |
71 | ||
72 | change that to something like this: | |
73 | ||
74 | [remote "origin"] | |
75 | url = ssh://perl5.git.perl.org/gitroot/perl.git | |
76 | ||
dc3c3040 GA |
77 | NOTE: there are symlinks set up so that the /gitroot is optional and |
78 | since SSH is the default protocol you can actually shorten the "url" to | |
79 | C<perl5.git.perl.org:/perl.git>. | |
d7dd28b6 | 80 | |
184487f0 NC |
81 | You can also set up your user name and e-mail address. For example |
82 | ||
83 | % git config user.name "Leon Brocard" | |
84 | % git config user.email acme@astray.com | |
85 | ||
6acba58e LB |
86 | It is also possible to keep C<origin> as a git remote, and add a new |
87 | remote for ssh access: | |
f6c12373 | 88 | |
dc3c3040 | 89 | % git remote add camel perl5.git.perl.org:/perl.git |
f6c12373 | 90 | |
6acba58e | 91 | This allows you to update your local repository by pulling from |
f755e97d | 92 | C<origin>, which is faster and doesn't require you to authenticate, and |
6acba58e | 93 | to push your changes back with the C<camel> remote: |
f6c12373 VP |
94 | |
95 | % git fetch camel | |
96 | % git push camel | |
97 | ||
6acba58e LB |
98 | The C<fetch> command just updates the C<camel> refs, as the objects |
99 | themselves should have been fetched when pulling from C<origin>. | |
f6c12373 | 100 | |
6a7cbfe8 LB |
101 | The committers have access to 2 servers that serve perl5.git.perl.org. |
102 | One is camel.booking.com, which is the 'master' repository. The | |
103 | perl5.git.perl.org IP address also lives on this machine. The second | |
104 | one is dromedary.booking.com, which can be used for general testing and | |
105 | development. Dromedary syncs the git tree from camel every few minutes, | |
106 | you should not push there. Both machines also have a full CPAN mirror. | |
107 | To share files with the general public, dromedary serves your | |
108 | ~/public_html/ as http://users.perl5.git.perl.org/~yourlogin/ | |
b47aa495 | 109 | |
d7dd28b6 LB |
110 | =head1 OVERVIEW OF THE REPOSITORY |
111 | ||
6acba58e LB |
112 | Once you have changed into the repository directory, you can inspect |
113 | it. | |
d7dd28b6 | 114 | |
39219fd3 | 115 | After a clone the repository will contain a single local branch, which |
50eca761 | 116 | will be the current branch as well, as indicated by the asterisk. |
39219fd3 YO |
117 | |
118 | % git branch | |
119 | * blead | |
120 | ||
f755e97d | 121 | Using the -a switch to C<branch> will also show the remote tracking |
6acba58e | 122 | branches in the repository: |
39219fd3 | 123 | |
d9847473 | 124 | % git branch -a |
09081495 | 125 | * blead |
d7dd28b6 LB |
126 | origin/HEAD |
127 | origin/blead | |
128 | ... | |
129 | ||
6acba58e LB |
130 | The branches that begin with "origin" correspond to the "git remote" |
131 | that you cloned from (which is named "origin"). Each branch on the | |
132 | remote will be exactly tracked by theses branches. You should NEVER do | |
133 | work on these remote tracking branches. You only ever do work in a | |
134 | local branch. Local branches can be configured to automerge (on pull) | |
135 | from a designated remote tracking branch. This is the case with the | |
136 | default branch C<blead> which will be configured to merge from the | |
137 | remote tracking branch C<origin/blead>. | |
39219fd3 | 138 | |
d7dd28b6 LB |
139 | You can see recent commits: |
140 | ||
c2cf2042 | 141 | % git log |
d7dd28b6 | 142 | |
6acba58e LB |
143 | And pull new changes from the repository, and update your local |
144 | repository (must be clean first) | |
d7dd28b6 LB |
145 | |
146 | % git pull | |
09081495 | 147 | |
6acba58e LB |
148 | Assuming we are on the branch C<blead> immediately after a pull, this |
149 | command would be more or less equivalent to: | |
39219fd3 YO |
150 | |
151 | % git fetch | |
152 | % git merge origin/blead | |
153 | ||
6acba58e LB |
154 | In fact if you want to update your local repository without touching |
155 | your working directory you do: | |
39219fd3 YO |
156 | |
157 | % git fetch | |
158 | ||
6acba58e LB |
159 | And if you want to update your remote-tracking branches for all defined |
160 | remotes simultaneously you can do | |
39219fd3 YO |
161 | |
162 | % git remote update | |
163 | ||
6acba58e LB |
164 | Neither of these last two commands will update your working directory, |
165 | however both will update the remote-tracking branches in your | |
166 | repository. | |
39219fd3 | 167 | |
09081495 LB |
168 | To switch to another branch: |
169 | ||
170 | % git checkout origin/maint-5.8-dor | |
171 | ||
6051489b NC |
172 | To make a local branch of a remote branch: |
173 | ||
174 | % git checkout -b maint-5.10 origin/maint-5.10 | |
175 | ||
09081495 LB |
176 | To switch back to blead: |
177 | ||
178 | % git checkout blead | |
c2cf2042 | 179 | |
39219fd3 YO |
180 | =head2 FINDING OUT YOUR STATUS |
181 | ||
182 | The most common git command you will use will probably be | |
183 | ||
184 | % git status | |
185 | ||
6acba58e LB |
186 | This command will produce as output a description of the current state |
187 | of the repository, including modified files and unignored untracked | |
188 | files, and in addition it will show things like what files have been | |
189 | staged for the next commit, and usually some useful information about | |
190 | how to change things. For instance the following: | |
39219fd3 YO |
191 | |
192 | $ git status | |
193 | # On branch blead | |
194 | # Your branch is ahead of 'origin/blead' by 1 commit. | |
195 | # | |
196 | # Changes to be committed: | |
197 | # (use "git reset HEAD <file>..." to unstage) | |
198 | # | |
199 | # modified: pod/perlrepository.pod | |
200 | # | |
201 | # Changed but not updated: | |
202 | # (use "git add <file>..." to update what will be committed) | |
203 | # | |
204 | # modified: pod/perlrepository.pod | |
205 | # | |
206 | # Untracked files: | |
207 | # (use "git add <file>..." to include in what will be committed) | |
208 | # | |
209 | # deliberate.untracked | |
210 | ||
6acba58e LB |
211 | This shows that there were changes to this document staged for commit, |
212 | and that there were further changes in the working directory not yet | |
213 | staged. It also shows that there was an untracked file in the working | |
214 | directory, and as you can see shows how to change all of this. It also | |
0549aefb LB |
215 | shows that there is one commit on the working branch C<blead> which has |
216 | not been pushed to the C<origin> remote yet. B<NOTE>: that this output | |
217 | is also what you see as a template if you do not provide a message to | |
218 | C<git commit>. | |
7f6effc7 YO |
219 | |
220 | Assuming we commit all the mentioned changes above: | |
221 | ||
222 | % git commit -a -m'explain git status and stuff about remotes' | |
223 | Created commit daf8e63: explain git status and stuff about remotes | |
224 | 1 files changed, 83 insertions(+), 3 deletions(-) | |
225 | ||
226 | We can re-run git status and see something like this: | |
227 | ||
228 | % git status | |
229 | # On branch blead | |
230 | # Your branch is ahead of 'origin/blead' by 2 commits. | |
231 | # | |
232 | # Untracked files: | |
233 | # (use "git add <file>..." to include in what will be committed) | |
234 | # | |
235 | # deliberate.untracked | |
236 | nothing added to commit but untracked files present (use "git add" to track) | |
237 | ||
39219fd3 | 238 | |
6acba58e LB |
239 | When in doubt, before you do anything else, check your status and read |
240 | it carefully, many questions are answered directly by the git status | |
241 | output. | |
39219fd3 | 242 | |
c2cf2042 LB |
243 | =head1 SUBMITTING A PATCH |
244 | ||
245 | If you have a patch in mind for Perl, you should first get a copy of | |
246 | the repository: | |
247 | ||
248 | % git clone git://perl5.git.perl.org/perl.git perl-git | |
249 | ||
250 | Then change into the directory: | |
251 | ||
252 | % cd perl-git | |
253 | ||
6acba58e LB |
254 | Alternatively, if you already have a Perl repository, you should ensure |
255 | that you're on the I<blead> branch, and your repository is up to date: | |
12322d22 A |
256 | |
257 | % git checkout blead | |
258 | % git pull | |
259 | ||
6a7cbfe8 LB |
260 | It's preferable to patch against the latest blead version, since this |
261 | is where new development occurs for all changes other than critical bug | |
262 | fixes. Critical bug fix patches should be made against the relevant | |
7f4ffa9d RS |
263 | maint branches, or should be submitted with a note indicating all the |
264 | branches where the fix should be applied. | |
a44f43ac | 265 | |
6acba58e LB |
266 | Now that we have everything up to date, we need to create a temporary |
267 | new branch for these changes and switch into it: | |
b1fccde5 | 268 | |
a9b05323 | 269 | % git checkout -b orange |
23f8d33e | 270 | |
a9b05323 YO |
271 | which is the short form of |
272 | ||
b1fccde5 LB |
273 | % git branch orange |
274 | % git checkout orange | |
275 | ||
c2cf2042 LB |
276 | Then make your changes. For example, if Leon Brocard changes his name |
277 | to Orange Brocard, we should change his name in the AUTHORS file: | |
278 | ||
279 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS | |
280 | ||
281 | You can see what files are changed: | |
282 | ||
283 | % git status | |
f755e97d | 284 | # On branch orange |
c2cf2042 LB |
285 | # Changes to be committed: |
286 | # (use "git reset HEAD <file>..." to unstage) | |
287 | # | |
288 | # modified: AUTHORS | |
289 | # | |
290 | ||
c2cf2042 LB |
291 | And you can see the changes: |
292 | ||
293 | % git diff | |
294 | diff --git a/AUTHORS b/AUTHORS | |
295 | index 293dd70..722c93e 100644 | |
296 | --- a/AUTHORS | |
297 | +++ b/AUTHORS | |
7df2e4bc | 298 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> |
c2cf2042 LB |
299 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> |
300 | Leif Huhn <leif@hale.dkstat.com> | |
301 | Len Johnson <lenjay@ibm.net> | |
302 | -Leon Brocard <acme@astray.com> | |
303 | +Orange Brocard <acme@astray.com> | |
304 | Les Peters <lpeters@aol.net> | |
305 | Lesley Binks <lesley.binks@gmail.com> | |
306 | Lincoln D. Stein <lstein@cshl.org> | |
307 | ||
308 | Now commit your change locally: | |
309 | ||
dc3c3040 | 310 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
c2cf2042 LB |
311 | Created commit 6196c1d: Rename Leon Brocard to Orange Brocard |
312 | 1 files changed, 1 insertions(+), 1 deletions(-) | |
313 | ||
dc3c3040 GA |
314 | You can examine your last commit with: |
315 | ||
316 | % git show HEAD | |
317 | ||
318 | and if you are not happy with either the description or the patch | |
c26da522 | 319 | itself you can fix it up by editing the files once more and then issue: |
dc3c3040 GA |
320 | |
321 | % git commit -a --amend | |
322 | ||
c2cf2042 LB |
323 | Now you should create a patch file for all your local changes: |
324 | ||
2af192ee | 325 | % git format-patch origin |
c2cf2042 LB |
326 | 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
327 | ||
328 | You should now send an email to perl5-porters@perl.org with a | |
dc3c3040 | 329 | description of your changes, and include this patch file as an |
c2cf2042 LB |
330 | attachment. |
331 | ||
b1fccde5 LB |
332 | If you want to delete your temporary branch, you may do so with: |
333 | ||
334 | % git checkout blead | |
335 | % git branch -d orange | |
336 | error: The branch 'orange' is not an ancestor of your current HEAD. | |
337 | If you are sure you want to delete it, run 'git branch -D orange'. | |
338 | % git branch -D orange | |
339 | Deleted branch orange. | |
7df2e4bc | 340 | |
a44f43ac RGS |
341 | =head2 A note on derived files |
342 | ||
343 | Be aware that many files in the distribution are derivative--avoid | |
0549aefb LB |
344 | patching them, because git won't see the changes to them, and the build |
345 | process will overwrite them. Patch the originals instead. Most | |
346 | utilities (like perldoc) are in this category, i.e. patch | |
347 | utils/perldoc.PL rather than utils/perldoc. Similarly, don't create | |
348 | patches for files under $src_root/ext from their copies found in | |
349 | $install_root/lib. If you are unsure about the proper location of a | |
350 | file that may have gotten copied while building the source | |
351 | distribution, consult the C<MANIFEST>. | |
a44f43ac RGS |
352 | |
353 | =head2 A note on binary files | |
354 | ||
0549aefb LB |
355 | Since the patch(1) utility cannot deal with binary files, it's |
356 | important that you either avoid the use of binary files in your patch, | |
357 | generate the files dynamically, or that you encode any binary files | |
358 | using the F<uupacktool.pl> utility. | |
a44f43ac RGS |
359 | |
360 | Assuming you needed to include a gzip-encoded file for a module's test | |
361 | suite, you might do this as follows using the F<uupacktool.pl> utility: | |
362 | ||
363 | $ perl uupacktool.pl -v -p -D lib/Some/Module/t/src/t.gz | |
364 | Writing lib/Some/Module/t/src/t.gz into lib/Some/Module/t/src/t.gz.packed | |
365 | ||
366 | This will replace the C<t.gz> file with an encoded counterpart. During | |
0549aefb LB |
367 | C<make test>, before any tests are run, perl's Makefile will restore |
368 | all the C<.packed> files mentioned in the MANIFEST to their original | |
369 | name. This means that the test suite does not need to be aware of this | |
370 | packing scheme and will not need to be altered. | |
a44f43ac RGS |
371 | |
372 | =head2 Getting your patch accepted | |
373 | ||
0549aefb LB |
374 | The first thing you should include with your patch is a description of |
375 | the problem that the patch corrects. If it is a code patch (rather | |
376 | than a documentation patch) you should also include a small test case | |
377 | that illustrates the bug (a patch to an existing test file is | |
378 | preferred). | |
a44f43ac RGS |
379 | |
380 | If you are submitting a code patch there are several other things that | |
381 | you need to do. | |
382 | ||
383 | =over 4 | |
384 | ||
385 | =item Comments, Comments, Comments | |
386 | ||
0549aefb LB |
387 | Be sure to adequately comment your code. While commenting every line |
388 | is unnecessary, anything that takes advantage of side effects of | |
a44f43ac | 389 | operators, that creates changes that will be felt outside of the |
0549aefb LB |
390 | function being patched, or that others may find confusing should be |
391 | documented. If you are going to err, it is better to err on the side | |
392 | of adding too many comments than too few. | |
a44f43ac RGS |
393 | |
394 | =item Style | |
395 | ||
0549aefb LB |
396 | In general, please follow the particular style of the code you are |
397 | patching. | |
a44f43ac | 398 | |
0549aefb LB |
399 | In particular, follow these general guidelines for patching Perl |
400 | sources: | |
a44f43ac RGS |
401 | |
402 | 8-wide tabs (no exceptions!) | |
403 | 4-wide indents for code, 2-wide indents for nested CPP #defines | |
404 | try hard not to exceed 79-columns | |
405 | ANSI C prototypes | |
406 | uncuddled elses and "K&R" style for indenting control constructs | |
407 | no C++ style (//) comments | |
408 | mark places that need to be revisited with XXX (and revisit often!) | |
409 | opening brace lines up with "if" when conditional spans multiple | |
410 | lines; should be at end-of-line otherwise | |
411 | in function definitions, name starts in column 0 (return value is on | |
412 | previous line) | |
413 | single space after keywords that are followed by parens, no space | |
414 | between function name and following paren | |
415 | avoid assignments in conditionals, but if they're unavoidable, use | |
416 | extra paren, e.g. "if (a && (b = c)) ..." | |
417 | "return foo;" rather than "return(foo);" | |
418 | "if (!foo) ..." rather than "if (foo == FALSE) ..." etc. | |
419 | ||
420 | =item Testsuite | |
421 | ||
0549aefb LB |
422 | When submitting a patch you should make every effort to also include an |
423 | addition to perl's regression tests to properly exercise your patch. | |
424 | Your testsuite additions should generally follow these guidelines | |
425 | (courtesy of Gurusamy Sarathy <gsar@activestate.com>): | |
a44f43ac RGS |
426 | |
427 | Know what you're testing. Read the docs, and the source. | |
428 | Tend to fail, not succeed. | |
429 | Interpret results strictly. | |
430 | Use unrelated features (this will flush out bizarre interactions). | |
431 | Use non-standard idioms (otherwise you are not testing TIMTOWTDI). | |
432 | Avoid using hardcoded test numbers whenever possible (the | |
433 | EXPECTED/GOT found in t/op/tie.t is much more maintainable, | |
434 | and gives better failure reports). | |
435 | Give meaningful error messages when a test fails. | |
436 | Avoid using qx// and system() unless you are testing for them. If you | |
437 | do use them, make sure that you cover _all_ perl platforms. | |
438 | Unlink any temporary files you create. | |
439 | Promote unforeseen warnings to errors with $SIG{__WARN__}. | |
440 | Be sure to use the libraries and modules shipped with the version | |
441 | being tested, not those that were already installed. | |
442 | Add comments to the code explaining what you are testing for. | |
443 | Make updating the '1..42' string unnecessary. Or make sure that | |
444 | you update it. | |
445 | Test _all_ behaviors of a given operator, library, or function: | |
446 | - All optional arguments | |
447 | - Return values in various contexts (boolean, scalar, list, lvalue) | |
448 | - Use both global and lexical variables | |
449 | - Don't forget the exceptional, pathological cases. | |
450 | ||
451 | =back | |
452 | ||
7df2e4bc LB |
453 | =head1 ACCEPTING A PATCH |
454 | ||
455 | If you have received a patch file generated using the above section, | |
456 | you should try out the patch. | |
457 | ||
458 | First we need to create a temporary new branch for these changes and | |
459 | switch into it: | |
460 | ||
a9b05323 | 461 | % git checkout -b experimental |
7df2e4bc | 462 | |
6acba58e LB |
463 | Patches that were formatted by C<git format-patch> are applied with |
464 | C<git am>: | |
7df2e4bc | 465 | |
2af192ee | 466 | % git am 0001-Rename-Leon-Brocard-to-Orange-Brocard.patch |
7df2e4bc LB |
467 | Applying Rename Leon Brocard to Orange Brocard |
468 | ||
6acba58e LB |
469 | If just a raw diff is provided, it is also possible use this two-step |
470 | process: | |
09645c26 VP |
471 | |
472 | % git apply bugfix.diff | |
dc3c3040 | 473 | % git commit -a -m "Some fixing" --author="That Guy <that.guy@internets.com>" |
09645c26 | 474 | |
7df2e4bc LB |
475 | Now we can inspect the change: |
476 | ||
dc3c3040 | 477 | % git show HEAD |
7df2e4bc LB |
478 | commit b1b3dab48344cff6de4087efca3dbd63548ab5e2 |
479 | Author: Leon Brocard <acme@astray.com> | |
480 | Date: Fri Dec 19 17:02:59 2008 +0000 | |
481 | ||
482 | Rename Leon Brocard to Orange Brocard | |
7df2e4bc | 483 | |
7df2e4bc LB |
484 | diff --git a/AUTHORS b/AUTHORS |
485 | index 293dd70..722c93e 100644 | |
486 | --- a/AUTHORS | |
487 | +++ b/AUTHORS | |
488 | @@ -541,7 +541,7 @@ Lars Hecking <lhecking@nmrc.ucc.ie> | |
489 | Laszlo Molnar <laszlo.molnar@eth.ericsson.se> | |
490 | Leif Huhn <leif@hale.dkstat.com> | |
491 | Len Johnson <lenjay@ibm.net> | |
492 | -Leon Brocard <acme@astray.com> | |
493 | +Orange Brocard <acme@astray.com> | |
494 | Les Peters <lpeters@aol.net> | |
495 | Lesley Binks <lesley.binks@gmail.com> | |
496 | Lincoln D. Stein <lstein@cshl.org> | |
497 | ||
498 | If you are a committer to Perl and you think the patch is good, you can | |
75fb7651 | 499 | then merge it into blead then push it out to the main repository: |
7df2e4bc LB |
500 | |
501 | % git checkout blead | |
d9847473 | 502 | % git merge experimental |
75fb7651 | 503 | % git push |
7df2e4bc LB |
504 | |
505 | If you want to delete your temporary branch, you may do so with: | |
506 | ||
507 | % git checkout blead | |
508 | % git branch -d experimental | |
509 | error: The branch 'experimental' is not an ancestor of your current HEAD. | |
510 | If you are sure you want to delete it, run 'git branch -D experimental'. | |
511 | % git branch -D experimental | |
512 | Deleted branch experimental. | |
b0d36535 YO |
513 | |
514 | =head1 CLEANING A WORKING DIRECTORY | |
515 | ||
6acba58e | 516 | The command C<git clean> can with varying arguments be used as a |
dc3c3040 | 517 | replacement for C<make clean>. |
b0d36535 YO |
518 | |
519 | To reset your working directory to a pristine condition you can do: | |
520 | ||
521 | git clean -dxf | |
522 | ||
523 | However, be aware this will delete ALL untracked content. You can use | |
524 | ||
525 | git clean -Xf | |
526 | ||
6acba58e LB |
527 | to remove all ignored untracked files, such as build and test |
528 | byproduct, but leave any manually created files alone. | |
b0d36535 | 529 | |
0549aefb | 530 | If you only want to cancel some uncommitted edits, you can use C<git |
c26da522 LB |
531 | checkout> and give it a list of files to be reverted, or C<git checkout |
532 | -f> to revert them all. | |
f755e97d RGS |
533 | |
534 | If you want to cancel one or several commits, you can use C<git reset>. | |
535 | ||
d82a90c1 VP |
536 | =head1 BISECTING |
537 | ||
6acba58e LB |
538 | C<git> provides a built-in way to determine, with a binary search in |
539 | the history, which commit should be blamed for introducing a given bug. | |
d82a90c1 | 540 | |
6acba58e LB |
541 | Suppose that we have a script F<~/testcase.pl> that exits with C<0> |
542 | when some behaviour is correct, and with C<1> when it's faulty. We need | |
543 | an helper script that automates building C<perl> and running the | |
544 | testcase: | |
d82a90c1 VP |
545 | |
546 | % cat ~/run | |
547 | #!/bin/sh | |
548 | git clean -dxf | |
549 | # If you can use ccache, add -Dcc=ccache\ gcc -Dld=gcc to the Configure line | |
c0d1ef72 MB |
550 | sh Configure -des -Dusedevel -Doptimize="-g" |
551 | test -f config.sh || exit 125 | |
552 | # Correct makefile for newer GNU gcc | |
553 | perl -ni -we 'print unless /<(?:built-in|command)/' makefile x2p/makefile | |
554 | # if you just need miniperl, replace test_prep with miniperl | |
555 | make -j4 test_prep | |
556 | -x ./perl || exit 125 | |
d82a90c1 | 557 | ./perl -Ilib ~/testcase.pl |
c0d1ef72 MB |
558 | ret=$? |
559 | git clean -dxf | |
560 | exit $ret | |
d82a90c1 | 561 | |
6acba58e LB |
562 | This script may return C<125> to indicate that the corresponding commit |
563 | should be skipped. Otherwise, it returns the status of | |
564 | F<~/testcase.pl>. | |
d82a90c1 VP |
565 | |
566 | We first enter in bisect mode with: | |
567 | ||
568 | % git bisect start | |
569 | ||
6acba58e LB |
570 | For example, if the bug is present on C<HEAD> but wasn't in 5.10.0, |
571 | C<git> will learn about this when you enter: | |
d82a90c1 VP |
572 | |
573 | % git bisect bad | |
574 | % git bisect good perl-5.10.0 | |
575 | Bisecting: 853 revisions left to test after this | |
576 | ||
6acba58e LB |
577 | This results in checking out the median commit between C<HEAD> and |
578 | C<perl-5.10.0>. We can then run the bisecting process with: | |
d82a90c1 VP |
579 | |
580 | % git bisect run ~/run | |
581 | ||
582 | When the first bad commit is isolated, C<git bisect> will tell you so: | |
583 | ||
584 | ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit | |
585 | commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 | |
586 | Author: Dave Mitchell <davem@fdisolutions.com> | |
587 | Date: Sat Feb 9 14:56:23 2008 +0000 | |
588 | ||
9469eb4a | 589 | [perl #49472] Attributes + Unknown Error |
d82a90c1 VP |
590 | ... |
591 | ||
592 | bisect run success | |
593 | ||
6acba58e LB |
594 | You can peek into the bisecting process with C<git bisect log> and |
595 | C<git bisect visualize>. C<git bisect reset> will get you out of bisect | |
596 | mode. | |
d82a90c1 | 597 | |
6acba58e LB |
598 | Please note that the first C<good> state must be an ancestor of the |
599 | first C<bad> state. If you want to search for the commit that I<solved> | |
600 | some bug, you have to negate your test case (i.e. exit with C<1> if OK | |
601 | and C<0> if not) and still mark the lower bound as C<good> and the | |
602 | upper as C<bad>. The "first bad commit" has then to be understood as | |
603 | the "first commit where the bug is solved". | |
d82a90c1 | 604 | |
6acba58e LB |
605 | C<git help bisect> has much more information on how you can tweak your |
606 | binary searches. | |
9d68b7ed | 607 | |
03050721 LB |
608 | =head1 SUBMITTING A PATCH VIA GITHUB |
609 | ||
610 | GitHub is a website that makes it easy to fork and publish projects | |
611 | with Git. First you should set up a GitHub account and log in. | |
612 | ||
613 | Perl's git repository is mirrored on GitHub at this page: | |
614 | ||
615 | http://github.com/github/perl/tree/blead | |
616 | ||
617 | Visit the page and click the "fork" button. This clones the Perl git | |
618 | repository for you and provides you with "Your Clone URL" from which | |
619 | you should clone: | |
620 | ||
621 | % git clone git@github.com:USERNAME/perl.git perl-github | |
622 | ||
623 | We shall make the same patch as above, creating a new branch: | |
624 | ||
625 | % cd perl-github | |
626 | % git remote add upstream git://github.com/github/perl.git | |
627 | % git pull upstream blead | |
628 | % git checkout -b orange | |
629 | % perl -pi -e 's{Leon Brocard}{Orange Brocard}' AUTHORS | |
dc3c3040 | 630 | % git commit -a -m 'Rename Leon Brocard to Orange Brocard' |
03050721 LB |
631 | % git push origin orange |
632 | ||
633 | The orange branch has been pushed to GitHub, so you should now send an | |
634 | email to perl5-porters@perl.org with a description of your changes and | |
635 | the following information: | |
636 | ||
637 | http://github.com/USERNAME/perl/tree/orange | |
638 | git@github.com:USERNAME/perl.git branch orange | |
639 | ||
c26da522 LB |
640 | =head1 MERGING FROM A BRANCH VIA GITHUB |
641 | ||
642 | If someone has provided a branch via GitHub and you are a committer, | |
5c9c28c6 | 643 | you should use the following in your perl-ssh directory: |
c26da522 LB |
644 | |
645 | % git remote add dandv git://github.com/dandv/perl.git | |
646 | % git fetch | |
647 | ||
648 | Now you can see the differences between the branch and blead: | |
649 | ||
650 | % git diff dandv/blead | |
651 | ||
652 | And you can see the commits: | |
653 | ||
654 | % git log dandv/blead | |
655 | ||
656 | If you approve of a specific commit, you can cherry pick it: | |
657 | ||
2bab0636 LB |
658 | % git cherry-pick 3adac458cb1c1d41af47fc66e67b49c8dec2323f |
659 | ||
660 | Or you could just merge the whole branch if you like it all: | |
661 | ||
662 | % git merge dandv/blead | |
c26da522 LB |
663 | |
664 | And then push back to the repository: | |
665 | ||
666 | % git push | |
667 | ||
9469eb4a | 668 | =head1 COMMITTING TO MAINTENANCE VERSIONS |
9d68b7ed | 669 | |
7f4ffa9d RS |
670 | Maintenance versions should only be altered to add critical bug fixes. |
671 | ||
9d68b7ed LB |
672 | To commit to a maintenance version of perl, you need to create a local |
673 | tracking branch: | |
674 | ||
675 | % git checkout --track -b maint-5.005 origin/maint-5.005 | |
676 | ||
0549aefb LB |
677 | This creates a local branch named C<maint-5.005>, which tracks the |
678 | remote branch C<origin/maint-5.005>. Then you can pull, commit, merge | |
679 | and push as before. | |
b0d36535 | 680 | |
f755e97d | 681 | You can also cherry-pick commits from blead and another branch, by |
0549aefb LB |
682 | using the C<git cherry-pick> command. It is recommended to use the |
683 | B<-x> option to C<git cherry-pick> in order to record the SHA1 of the | |
684 | original commit in the new commit message. | |
f755e97d RGS |
685 | |
686 | =head1 SEE ALSO | |
687 | ||
688 | The git documentation, accessible via C<git help command>. | |
0549aefb | 689 |