Managing Xen Patches with Git

Generating a patch

---

Here's a recommendation on how to create patches using git, as suggested by the Xen Project maintainers.

The instructions on this page use the most common git workflow: aka the patch series is developed on a git branch. Many people find this difficult to work with. There are some alternatives StGit is 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 Submitting_Xen_Patches_with_StGit. Patman is a Python script originally developed for U-Boot (but it also should work with Xen), which creates patches directly from your branch, cleans them up by removing unwanted tags, inserts a cover letter with change lists, ... This tool is useful for specially for long series that you expect to resend a couple of times. Patman is available from http://git.denx.de/?p=u-boot.git;a=tree;f=tools/patman (also see the README).

If you want to use mercurial, please see Submitting_Xen_Patches_-_mercurial.

---

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.

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

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