Controlling Dependency in new Gerrit Patches

Gerrit Patches and Dependency

## Checking out unmerged patches
So you've decided to work on a new patch that depends on another that's still under review. There's no need to wait for it to be merged. Gerrit allows you to check out any patch easily

[Imgur](http://i.imgur.com/7xqC5JH.png)

On each patch's page, there's a text-box with the commands to *checkout*, *pull*, *cherry-pick* and *patch* each particular patchset. You want to work on top of an existing patch so go ahead and check it out.


## Housekeeping

### Branch naming
When checking out the patch, git will put you in a DETACHED HEAD state. Be sure to name the branch exactly as the topic branch it was from on Gerrit, for example `git checkout -b bp/glance-api-v2-tests`.

You can now work on the patch as usual.

### Submitting your new patch
When you're satisfied with your addition/changes, be sure to add them as a **new** git commit, **DO NOT USE `--amend`**. Remember, you want a fresh patch on Gerrit, not a patchset to an existing one.

`git-review` will list the parent commit and your new commit when staging your patch.

[Imgur](http://i.imgur.com/NgFRmoH.png)

The original patch you checked out might've received new patchsets while you were working on yours, so you can eithe rebase before submiting like so: `git pull --rebase https://review.openstack.org/stackforge/cloudroast refs/changes/81/49381/4`

Otherwise, Gerrit will show that the dependency is *outdated* on your patch page so you'll have to rebase before it's merged anyway.


## Glossary
1. *commit* - An atomic collection of changes in `git`.
   
2. *patch* - A change that's submitted to Gerrit.

3. *patchset* - A subset of a *patch* that's submitted to Gerrit, addressing reviewer comments or amending code.