Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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.
- 
- 
- 
- 
- 
- 

Navigation

* [[:start|Home]] * [[:about|About our Project]] * [[:download|Download]] * [[:screenshots|Screenshots]] * Documentation * [[:howtos|HowTo Guides]] * [[:appnotes|Application Notes]] * [[:faq:|FAQs]] * [[:doc|General Doc]] * [[:talks|Videos, Talks, and Papers]] * [[:hardwareissues|Hardware Issues]] * [[:mailinglists|Mailing lists]] * [[http://support.etherboot.org/|Bugtracker]] * [[:contributing|Contributing]] * [[:editing_permission|Wiki Edit Permission]] * [[:wiki:syntax|Wiki Syntax]] * [[:contact|Contact]] * [[:relatedlinks|Related Links]] * [[:commerciallinks|Commercial Links]] * [[:acknowledgements|Acknowledgements]] * [[:logos|Logo Art]]

QR Code
QR Code staging (generated for current page)