Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
staging [2009/11/21 18:36] mdc |
staging [2009/11/22 20:25] mdc |
||
---|---|---|---|
Line 3: | Line 3: | ||
{{ :bootrom.jpeg?120x96|A boot ROM}} | {{ :bootrom.jpeg?120x96|A boot ROM}} | ||
- | The [[http://git.etherboot.org/?p=gpxe-staging.git|staging tree]] is used to hold branches with patches for review and merging into the [[http://git.etherboot.org/?p=gpxe.git|main gPXE tree]]. It provides a central location for collecting patches submitted via the mailing list, IRC, and other methods. | + | The [[http://git.etherboot.org/?p=gpxe-staging.git|staging tree]] is used to hold branches waiting for potential merging into the [[http://git.etherboot.org/?p=gpxe.git|main gPXE tree]]. It provides a central location for collecting patches submitted via the mailing list, IRC, and other methods. |
Most branches in the staging tree hold individual features, such as a new driver, and are referred to as "feature branches". | Most branches in the staging tree hold individual features, such as a new driver, and are referred to as "feature branches". | ||
- | Once a feature branch is merged into the main gPXE tree, it will be deleted from the staging tree. | + | After a feature branch is merged into the main gPXE tree, it is deleted from the staging tree. |
===== Trying out a feature branch ===== | ===== Trying out a feature branch ===== | ||
Line 90: | Line 90: | ||
* Each commit should be reviewable as a standalone unit that makes sense from the point of view of the tree as a whole. For example, a new feature branch that requires some changes to the net device core API should contain at least two commits: one commit to change the net device core API (and to fix up all code affected by this change) and one or more commits to then introduce the new feature. | * Each commit should be reviewable as a standalone unit that makes sense from the point of view of the tree as a whole. For example, a new feature branch that requires some changes to the net device core API should contain at least two commits: one commit to change the net device core API (and to fix up all code affected by this change) and one or more commits to then introduce the new feature. | ||
- | * There should be no trace of partially-working attempts, abandoned ideas, temporary hacks, and so on. Commands such as <code>git rebase --interactive</code> and <code>git commit --amend</code> can be very useful in tidying up a branch so that it is ready to be submitted. | + | * There should be no trace of partially-working attempts, abandoned ideas, temporary hacks, and so on. Commands such as: |
+ | |||
+ | $ git rebase --interactive | ||
+ | |||
+ | and | ||
+ | |||
+ | $ git commit --amend | ||
+ | |||
+ | can be very useful in tidying up a branch so that it is ready to be submitted. | ||
* Each commit must be buildable in its own right. For example, do not introduce a C file in one commit that depends upon a header introduced only in a later commit. | * Each commit must be buildable in its own right. For example, do not introduce a C file in one commit that depends upon a header introduced only in a later commit. | ||
Line 169: | Line 177: | ||
sponsor_name-task_number-feature_branch_name-ready | sponsor_name-task_number-feature_branch_name-ready | ||
- | This is an indication to reviewers that the feature has now been handed off for final merge review to a main repository maintainer. | + | This is an indication to main branch maintainers that the feature is now ready for final merge review. |
Note to staging tree maintainers: | Note to staging tree maintainers: | ||
Line 207: | Line 215: | ||
$ git am < new_feature_v2.patch | $ git am < new_feature_v2.patch | ||
$ git push staging sponsor_name-task_number-feature_branch_name_v2 | $ git push staging sponsor_name-task_number-feature_branch_name_v2 | ||
- | |||
==== Some useful git commands for staging maintainers ==== | ==== Some useful git commands for staging maintainers ==== | ||
=== Ways to view the staging repository === | === Ways to view the staging repository === | ||
+ | |||
+ | == View compact listing of remote branches == | ||
$ git branch -r -v | $ git branch -r -v | ||
+ | |||
+ | == Look at staging branch commits == | ||
+ | |||
$ git log staging/branch_name | $ git log staging/branch_name | ||
+ | |||
+ | == Show commits in staging branch not in main branch == | ||
+ | |||
+ | $ git cherry -v HEAD staging/branch_name | ||
=== Prune remote branches from local repository === | === Prune remote branches from local repository === | ||
Line 234: | Line 250: | ||
The ":" character before the remote_branch_name is required for the push to work. | The ":" character before the remote_branch_name is required for the push to work. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- |