anchor.diff:  * If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and upload the new one, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>.
     Cancel the Patch Available flag and then re-trigger it, by toggling the btn:[Patch Available] button in JIRA.
     JIRA sorts attached files by the time they were attached, and has no problem with multiple attachments with the same name.
  -  However, at times it is easier to refer to different version of a patch if you add `-vX`, where the [replaceable]_X_ is the version (starting with 2).
  -* If you need to submit your patch against multiple branches, rather than just master, name each version of the patch with the branch it is for, following the naming conventions in <<submitting.patches.create,submitting.patches.create>>.
  +  However, at times it is easier to increment patch number in the patch name.
   
   [[patching.methods]]
   .Methods to Create Patches
  
positive.code: [[submitting.patches.create]]
  ==== Create Patch
  
  The script _dev-support/make_patch.sh_ has been provided to help you adhere to patch-creation guidelines.
  The script has the following syntax:
  
  ----
  $ make_patch.sh [-a] [-p <patch_dir>]
  ----
  
  . If you do not pass a `patch_dir`, the script defaults to _~/patches/_.
    If the `patch_dir` does not exist, it is created.
  . By default, if an existing patch exists with the JIRA ID, the version of the new patch is incremented (_HBASE-XXXX-v3.patch_). If the `-a`                            option is passed, the version is not incremented, but the suffix `-addendum` is added (_HBASE-XXXX-v2-addendum.patch_). A second addendum to a given version is not supported.
  . Detects whether you have more than one local commit on your branch.
    If you do, the script offers you the chance to run +git rebase
    -i+ to squash the changes into a single commit so that it can use +git format-patch+.
    If you decline, the script uses +git diff+ instead.
    The patch is saved in a configurable directory and is ready to be attached to your JIRA.
  
  .Patching Workflow
  
  
negative.code: * 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.
  * 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.
  
  * To submit a patch, first create it using one of the methods in <<patching.methods,patching.methods>>.
    Next, attach the patch to the JIRA (one patch for the whole fix), using the  dialog.
  