** {{git branch bug_666 gerrit/\[BRANCH_NAME\]}}
*** For example: {{git branch bug_666 gerrit/master}}
** {{git checkout bug_666}}
* Make all of the topic-specific changes on you branch.
* {{git push gerrit HEAD:refs/for/\[BRANCH_NAME\]}}
** For example: {{git push gerrit HEAD:refs/for/master}}
You should next go into the gerrit's web page for the change's and add reviewers. Otherwise, it's unlikely anyone will review your code. Adding a reviewer causes the change to show up in the reviewer's "Reviewable by me" list, and they also get an email.
Others will go and review your code (you can also request reviews specifically in the admin UI).
h1. Review Workflow
It's good to learn the key combinations (hit ? anywhere), but in general, you can see all of the open changes by going to All \-> Open and digging through them.
h3. Phase 1: Reviewable
Dig around, look at things to review, and throw in your comments. You can comment on individual code lines.
Also, with regards to dependencies, if the fix you're reviewing depends on another fix, review the dependency first. That is, follow the dependency link trail until you hit a fix that has no dependencies. This helps ensure the right cherry-pick sequencing (gerrit does cherry-picking automatically for us if we do it right).
It takes two points for code to be acceptable. Everyone has two points to spend on a given change. Use them wisely.
h2. Phase 2: Needs verification
You can do this at the same time as the review, but you have the ability to pull down the changes to test locally.
h2. Phase 2.5: Rejected\!
If your code was rejected, it's time for a fix and retry: Fix, rebase, repeat (the Change-Id will keep old comments in sync).
* {{git checkout my-rejected-topic-branch}}
* {{$EDITOR broken-file.erl}}
* \# Rebase against the current upstream, fixup changes while maintaining Change-Id
* {{git rebase \-i gerrit/\[BRANCH_NAME\]}}
** For example: {{git rebase \-i gerrit/master}}
* {{git push gerrit HEAD:refs/for/\[BRANCH_NAME\]}}
** For example: {{git push gerrit HEAD:refs/for/master}}
The rebase session will begin with you in an editor that looks something like the one to the right:
At this point, your current patch should be replaced with the new, fixed up version.
h2. Phase 3: Submit
Once the change is all verified, we can submit. We use cherry-pick, which means we need to be a bit careful to do this in order.
Once the submit is complete, the change will automatically show up on github, as we publish changes there too.
h1. Links
For a good primer on Gerrit:
[Gerrit Code Review at Wikibooks|http://en.wikibooks.org/wiki/Git/Gerrit_Code_Review#Submitting_changes_for_review]
{color:#29afdf}{*}Commit Tips and Style Hints{*}{color}
* The best commit messages are like little blog posts.
** These can help to "sell" your commit to the community.
* Here's examples where the commit message was much longer than the actual fix, but provided useful context as those one-liner fixes can sometimes be very intricate...
** [Change 652|http://review.membase.org/652]
** [Change 963|http://review.membase.org/963]
* On style, don't have giant long lines, especially on your first summary line.
* The best commits, too, are just like UNIX Philosophy.
** The commit does one thing and does it well.
** That is, a giant commit will probably be need to be broken up into smaller, bite-sized, easier to-digest commits.
...