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 gerrit for 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
- 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
- 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
