anchor.diff:  +
   .Example of committing a Patch
   ====
  -One thing you will notice with these examples is that there are a lot of +git pull+ commands.
  -The only command that actually writes anything to the remote repository is +git push+, and you need to make absolutely sure you have the correct versions of everything and don't have any conflicts before pushing.
  -The extra +git
  -                                        pull+ commands are usually redundant, but better safe than sorry.
  -
  -The first example shows how to apply a patch that was generated with +git format-patch+ and apply it to the `master` and `branch-1` branches.
  -
  -The directive to use +git format-patch+                                    rather than +git diff+, and not to use `--no-prefix`, is a new one.
  -See the second example for how to apply a patch created with +git
  -                                        diff+, and educate the person who created the patch.
  +One thing you will notice with these examples is that there are a lot of
  ++git pull+ commands. The only command that actually writes anything to the
  +remote repository is +git push+, and you need to make absolutely sure you have
  +the correct versions of everything and don't have any conflicts before pushing.
  +The extra +git pull+ commands are usually redundant, but better safe than sorry.
  +
  +The first example shows how to apply a patch that was generated with +git
  +format-patch+ and apply it to the `master` and `branch-1` branches.
  +
  +The directive to use +git format-patch+ rather than +git diff+, and not to use
  +`--no-prefix`, is a new one. See the second example for how to apply a patch
  +created with +git diff+, and educate the person who created the patch.
   
   ----
   $ git checkout -b HBASE-XXXX
  
positive.code: ====
  
  . Resolve the issue as fixed, thanking the contributor.
    Always set the "Fix Version" at this point, but please only set a single fix version for each branch where the change was committed, the earliest release in that branch in which the change will appear.
  
  ====== Commit Message Format
  
  
negative.code: [NOTE]
  ====
  Make sure your local configuration is correct, especially your identity and email.
  Examine the output of the +$ git config --list+ command and be sure it is correct.
  See link:https://help.github.com/articles/set-up-git[Set Up Git] if you need
  pointers.
  ====
  
  When you commit a patch:
  
  . Include the Jira issue ID in the commit message along with a short description
    of the change. Try to add something more than just the Jira title so that
    someone looking at `git log` output doesn't have to go to Jira to discern what
    the change is about. Be sure to get the issue ID right, because this causes
    Jira to link to the change in Git (use the issue's "All" tab to see these
    automatic links).
  . Commit the patch to a new branch based off `master` or the other intended
    branch. It's a good idea to include the JIRA ID in the name of this branch.
    Check out the relevant target branch where you want to commit, and make sure
    your local branch has all remote changes, by doing a +git pull --rebase+ or
    another similar command. Next, cherry-pick the change into each relevant
    branch (such as master), and push the changes to the remote branch using
    a command such as +git push <remote-server> <remote-branch>+.
  +
  WARNING: If you do not have all remote changes, the push will fail.
  If the push fails for any reason, fix the problem or ask for help.
  Do not do a +git push --force+.
  +
  Before you can commit a patch, you need to determine how the patch was created.
  The instructions and preferences around the way to create patches have changed,
  and there will be a transition period.
  +
  .Determine How a Patch Was Created
  * If the first few lines of the patch look like the headers of an email, with a From, Date, and
  