anchor.diff:  
   ----
   $ git apply ~/Downloads/HBASE-XXXX-v2.patch
  -$ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" -a # This extra step is needed for patches created with 'git diff'
  +$ git commit -m "HBASE-XXXX Really Good Code Fix (Joe Schmo)" --author=<contributor> -a  # This
  +and next command is needed for patches created with 'git diff'
  +$ git commit --amend --signoff
   $ git checkout master
   $ git pull --rebase
   $ git cherry-pick <sha-from-commit>
   # Resolve conflicts if necessary or ask the submitter to do it
   $ git pull --rebase          # Better safe than sorry
   $ git push origin master
  +
  +# Backport to branch-1
   $ git checkout branch-1
   $ git pull --rebase
   $ git cherry-pick <sha-from-commit>
  
positive.code: [[common.patch.feedback.trailingspaces]]
  ===== Trailing Spaces
  
  Trailing spaces are a common problem.
  Be sure there is a line break after the end of your code, and avoid lines with nothing but whitespace.
  This makes diffs more meaningful.
  You can configure your IDE to help with this.
  
negative.code: [[submitting.patches]]
  === Submitting Patches
  
  If you are new to submitting patches to open source or new to submitting patches to Apache, start by
   reading the link:http://commons.apache.org/patches.html[On Contributing Patches] page from
   link:http://commons.apache.org/[Apache Commons Project].
  It provides a nice overview that applies equally to the Apache HBase Project.
  link:http://accumulo.apache.org/git.html[Accumulo doc on how to contribute and develop] is also
  good read to understand development workflow.
  
  [[submitting.patches.create]]
  ==== Create Patch
  
  Make sure you review <<common.patch.feedback,common.patch.feedback>> for code style. If your
  patch
  was generated incorrectly or your code does not adhere to the code formatting guidelines, you may
  be asked to redo some work.
  
  
  .Using submit-patch.py (recommended)
  
  [source,bourne]
  ----
  $ dev-support/submit-patch.py -jid HBASE-xxxxx
  ----
  
  Use this script to create patches, upload to jira and optionally create/update reviews on
  Review Board. Patch name is automatically formatted as _(JIRA).(branch name).(patch number).patch_
   to follow Yetus' naming rules. Use `-h` flag to know detailed usage information. Most useful options
  are:
  
  * `-b BRANCH, --branch BRANCH` : Specify base branch for generating the diff. If not specified,
  tracking branch is used. If there is no tracking branch, error will be thrown.
  * `-jid JIRA_ID, --jira-id JIRA_ID` : If used, deduces next patch version from attachments in the
  jira and uploads the new patch. Script will ask for jira username/password for authentication.
  If not set, patch is named <branch>.patch.
  
  By default, it'll also create/update review board. To skip that action, use `-srb` option. It uses
  'Issue Links' in the jira to figure out if a review request already exists. If no review
  request is present, then creates a new one and populates all required fields using jira summary,
  patch description, etc. Also adds this review's link to the jira.
  
  Save authentication credentials (optional)::
  Since attaching patches on JIRA and creating/changing review request on ReviewBoard requires
  valid user authentication, the script will prompt you for username and password. To avoid the hassle every
  time, set up `~/.apache-creds` with login details and encrypt it by following the steps in footer
  of script's help message.
  
  Python dependencies:: To install required python dependencies, execute
  `pip install -r dev-support/python-requirements.txt` from the master branch.
  
  .Manually
  
    . Use `git rebase -i` first, to combine (squash) smaller commits into a single larger one.
    . Create patch using IDE or Git commands. `git format-patch` is preferred since it preserves patch
      author's name and commit message. Also, it handles binary files by default, whereas `git diff`
      ignores them unless you use the `--binary` option.
    . Patch name should be as follows to adhere to Yetus' naming convention: +
      `(JIRA).(branch name).(patch number).patch` +
      For eg. HBASE-11625.master.001.patch, HBASE-XXXXX.branch-1.2.0005.patch, etc.
    . Attach the patch to the JIRA using `More->Attach Files` then click on btn:[Submit Patch]
      button, which'll trigger Hudson job to check patch for validity.
    . If your patch is longer than a single screen, also create a review on Review Board  and
      add the link to JIRA. See <<reviewboard,reviewboard>>.
  
  
  
  .Few general guidelines
  * Always patch against the master branch first, even if you want to patch in another branch.
    HBase committers always apply patches first to the master branch, and backport if necessary.
  * Submit one single patch for a fix. If necessary, squash local commits to merge local commits into
    a single one first. See this
    link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow
    question] for more information about squashing commits.
  * Please understand that not every patch may get committed, and that feedback will likely be
    provided on the patch.
  * If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and
    upload a new one with incremented patch number. +
    Click on btn:[Cancel Patch] and then on btn:[Submit Patch] to trigger the presubmit run.
  
  [[submitting.patches.tests]]
  ==== Unit Tests
  Always add and/or update relevant unit tests when making the changes.
  Make sure that new/changed unit tests pass locally before submitting the patch because it is faster
  than waiting for presubmit result which runs full test suite. This will save your own time and
  effort.
  Use <<mockito,mockito>> to make mocks which are very useful for testing failure scenarios by
  injecting appropriate failures.
  
  If you are creating a new unit test class, notice how other unit test classes have
  classification/sizing annotations before class name and a static methods for setup/teardown of
  testing environment. Be sure to include annotations in any new unit test files.
  See <<hbase.tests,hbase.tests>> for more information on tests.
  
  ==== Integration Tests
  
  