The patch dance - OpenStack style.
Originally published .
If you are working on patches for OpenStack and you find yourself building patches that rely on other patches… what do you do? Well, you could maintain all your patches in one big directory and hope not to screw something up or “cross the files” but that would be down right lazy.
Seriously… lazy in the bad way… not at all lazy in the good way.
The right way to do things is a git branch per bug (or blueprint related patch) and then to rebase each “down-stream” bug from your appropriate “up-stream” bugs. That means you need to create a kind of “bug dependency” chart maintaining a tree like relationship between the various bugs.
As a prerequisite, I’ll assume you followed:
- http://docs.openstack.org/developer/nova/devref/development.environment.html
- https://wiki.openstack.org/wiki/GerritWorkflow
If you were a dummy and you managed to submit your first review on *master *(oh you fool!) then how do you fix this? Assuming your patch is safely up in gerritfor review already…
- roll back your master to head
- create a new local branch for your bug number
- use the “patch” link for your patch in gerrit
- after applying the patch, commit again and paste your old message in as the new commit message
The trick that makes this work is the special Change-Id:xxxxxxxx line at the end of the original message. This will tell gerrit to take your incoming patch as a new version of the old change.
What happens if you need to rebase your patch?
- git check out the master
- git fetch –all
- check out your bug branch
-
git rebase master What happens if you need to have bug B based on bug A?
- git checkout master
- git fetch –all
- git branch bug/A
- git checkout bug/A
- do work for bug/A and possibly submit it to git review
- git checkout bug/A
- git branch bug/B
- git checkout bug/B
-
do work for bug/B and possibly submit separately Need to make sure the master hasn’t drifted under bug A and B?
- git checkout master
- git fetch –all
- git checkout bug/A
- git rebase master
- … conflicts better result in your changing only code touched in bug/A or see the trick for how to “move” a patch to a branch above …
- git checkout bug/B
- git rebase bug/A The key is to keep the dependencies clean, feeding the master, then sliding up the branch dependency tree one bug at a time pulling forward the rebase from the last branch. Keeping each branch and patch separate should make other aspects of your life easier.