← Back to branch summary

~ubuntu-branches/ubuntu/raring/parrot/raring-proposed

« back to all changes in this revision

Viewing changes to docs/project/git_workflow.pod

  • Committer: Bazaar Package Importer
  • Author(s): Allison Randal
  • Date: 2011-07-30 18:45:03 UTC
  • mfrom: (1.1.13 upstream)
  • Revision ID: james.westby@ubuntu.com-20110730184503-34d4mprtfx6pt5h3
Tags: 3.6.0-1
* New upstream release
* debian/watch:
  - Modified regular expression to capture numbered directory name
    (patch from Dominique Dumont).
* debian/rules:
  - Split build-arch and build-indep, resolving lintian warning.
  - Update path to pbc_disassemble for manpage generation (patch
    from Dominique Dumont).
* debian/patches:
  - Added patch 02_fix_perl_interpreter_path.patch, resolving
    lintian warnings.
* debian/control:
  - Added DM-Upload-Allowed field.

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/project/git_workflow.pod
14
14
keeping others. Git provides many powerful tools in the maintenance of
15
15
branches. This document aims to provide everything a Parrot developer needs to
16
16
know about Git to successfully create a branch, work on it, keep it in sync
17
 
with changes on master and finally merge the branch.
 
17
with changes on master and finally merge the branch (or send a pull request).
18
18
 
19
19
=head2 Cloning the Git Repository
20
20
 
128
128
 
129
129
  git add foo.c bar.c
130
130
 
131
 
The command C<git add> is not only for adding new files, just keep that in mind.
132
 
It tells git "add the state of these files to my staging area."
 
131
The command C<git add> is not only for adding new files, just keep that in
 
132
mind.  It tells git "add the *current* state of these files to my staging
 
133
area." If these files change after you C<git add> them, they will need to be
 
134
added again.
133
135
 
134
136
If you are trying to add files that are in .gitignore, you can do that with
135
137
the --force flag:
368
370
 
369
371
NOTE: This is not official policy, and could change at any time.
370
372
 
 
373
ALSO NOTE: With the introduction of the magical Github Merge Button, doesn't
 
374
this seem like a ridiculous amount of work to accept code from a fork? This
 
375
workflow is still useful if you want to run tests or do any other analysis
 
376
on the pull request.
 
377
 
371
378
If you are merging code from non-core committers, Parrot would like to see
372
379
"Signed-off-by" lines on each commit, so it is clear that one person wrote the
373
380
code and someone else is taking responsibility for merging the code.
374
381
 
375
 
To merge in a pull request on Github, the following method should be used.
376
 
Follow the first two steps on the Github pull request page, i.e:
 
382
To merge in a pull request on Github, there is the easy way or the hard way.
 
383
The easy way is to use tools/dev/merge_pull_request.pl like so:
 
384
 
 
385
    perl $PARROT/tools/dev/merge_pull_request.pl N
 
386
 
 
387
where N is the number of the pull request. This will create a branch for the
 
388
pull request and plop you on it, so that tests or other analyses can be run.
 
389
 
 
390
This script can be used to merge a pull request for any repo in the Parrot
 
391
Github Organization. For instance, to merge Cardinal Pull request #4:
 
392
 
 
393
 perl $PARROT/tools/dev/merge_pull_request.pl 4 cardinal
 
394
 
 
395
If you do not want the default branch name, you can specify a third
 
396
argument to specify one:
 
397
 
 
398
 perl $PARROT/tools/dev/merge_pull_request.pl 4 cardinal awesome_feature
 
399
 
 
400
This will merge pull request #4 in the cardinal repo into a branch
 
401
called 'awesome_feature'.
 
402
 
 
403
Run C<perldoc tools/dev/merge_pull_request.pl> for more info.
 
404
 
 
405
The hard way: Follow the first two steps on the Github pull request page, i.e:
377
406
 
378
407
    # 1) Make a new branch to pull stuff into
379
408
    git checkout -b someguy-newbranch master