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