Managing Xen Patches with Git: Difference between revisions
Lars.kurth (talk | contribs) (Rework this, such that it fits with Submitting Xen Project Patches) |
Lars.kurth (talk | contribs) No edit summary |
||
Line 58: | Line 58: | ||
$ git commit |
$ git commit |
||
</syntaxhighlight> |
</syntaxhighlight> |
||
'''Important:''' The conventions related to what should be in commit messages are described in [[Submitting Xen Project Patches]]. |
|||
Alternatively, you can commit all changes using "git commit -a": |
Alternatively, you can commit all changes using "git commit -a": |
||
Line 76: | Line 78: | ||
Make as many commits on your new branch as are necessary. |
Make as many commits on your new branch as are necessary. |
||
If you want to make a local branch based on <code>staging</code> rather than <code>master</code> (for example, to fix a changeset which has caused the XenProject.org nightly testing to fail), you can do the following: |
If you want to make a local branch based on <code>staging</code> rather than <code>master</code> (for example, to fix a changeset which has caused the XenProject.org nightly testing to fail), you can do the following: |
||
<syntaxhighlight lang="sh" highlight="1"> |
<syntaxhighlight lang="sh" highlight="1"> |
Revision as of 12:16, 7 August 2019
This document assumes that you are familiar with the following documents
- Xen Project Repositories
- Submitting Xen Project Patches - the document explains conventions related to cover letters, *-by tags, etc. as well as the tooling involved in sending patches and patch series
It lays out basic examples and best practice of how to use Git to manage Xen patches as part of the submission process.
Similar documents exist for
- StGit, a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of Git. You can find instructions at Managing Xen Patches with StGit.
Generating a patch
Begin by cloning the git repo from XenProject.org:
$ git clone git://xenbits.xenproject.org/xen.git xen.git
At this point you should have xenbits
set up as the remote repostiory called "origin":
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/stable-4.0
remotes/origin/stable-4.1
remotes/origin/stable-4.2
remotes/origin/staging
remotes/origin/staging-4.0
remotes/origin/staging-4.1
remotes/origin/staging-4.2
This process automatically creates a local branch called master
that will track the XenProject.org branch called master
.
The branch called staging
is the bleeding-edge of commits; this is tested regularly with the xen.org
build and regression testing system, and when it pases, is pushed to the master
branch. It is suggested to develop patches based on the master
branch.
Important: When you want to introduce a change, start by making a new branch based on the most recent change in the master
branch:
$ git checkout -b out/trondle-calls master
Switched to a new branch 'out/trondle-calls'
Then edit the source files you want to change. You can see which files have changed by using git status
.
When you're done editing, use git add
to specify which file changes you want included in the changeset, and then use git commit
to make a commit. You will be prompted to make a changset description:
$ git status
# On branch out/trondle-calls
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foobar/zot.c
# modified: foobar/zot.h
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add foobar/zot.c foobar/zot.h
$ git commit
Important: The conventions related to what should be in commit messages are described in Submitting Xen Project Patches.
Alternatively, you can commit all changes using "git commit -a":
$ git commit -a
foobar: Add a new trondle calls
Add a some new trondle calls to the foobar interface to support
the new zot feature.
Signed-off-by: Joe Smith <joe.smith@citrix.com>
Make as many commits on your new branch as are necessary.
If you want to make a local branch based on staging
rather than master
(for example, to fix a changeset which has caused the XenProject.org nightly testing to fail), you can do the following:
$ git checkout -b staging remotes/origin/staging
Branch staging set up to track remote branch staging from origin.
Switched to a new branch 'staging'
Then in the commands above, you would use "staging" instead of "master" as the base branch. ...
Sending a patch to xen-devel@
You can find instructions on how to send patches in our Patch Submission Guide.