| - Make small logical changes.
| - Provide a meaningful commit message.
| - Review and follow the Eclipse Due Diligence Process
| - Review and follow the current guidelines:
|I wanted a file describing how to submit patches for JGit,
|so I started with the one found in the core Git distribution
|(Documentation/SubmittingPatches), which itself was based on the
|patch submission guidelines for the Linux kernel.
|However there are quite a few differences, so please review and
|familiarize yourself with the following relevant bits:
|(1) Make separate commits for logically separate changes.
|Unless your patch is really trivial, you should not be sending
|out a patch that was generated between your working tree and your
|commit head. Instead, always make a commit with complete commit
|message and generate a series of patches from your repository.
|It is a good discipline.
|Describe the technical detail of the change(s).
|If your description starts to get too long, that's a sign that you
|probably need to split up your commit to finer grained pieces.
|I am very picky about formatting. Make sure your final version
|of every file was formatted using the Eclipse code formatter
|using the project specific settings (Properties->Java Code
|Style->Formatter->"Java Conventions [built-in]").
|(2) Generate your patch using git tools out of your commits.
|git based diff tools (git, and StGIT included) generate unidiff,
|which is the only acceptable format.
|You do not have to be afraid to use -M option to "git diff" or "git
|format-patch", if your patch involves file renames. The receiving
|end can handle them just fine.
|Please make sure your patch does not include any extra files which
|do not belong in a patch submission. Make sure to review your
|patch after generating it, to ensure accuracy. Before sending out,
|please make sure it cleanly applies to the "master" branch head.
|(3) Check the license.
|JGit is licensed under the Eclipse Distribution License (EDL,
|http://www.eclipse.org/org/documents/edl-v10.html), which is a
|renamed version of the new style/3-clause BSD license.
|Under this licensing model *every* file within the project
|*must* list which license covers it in the header of the file.
|Any new contributions to an existing file *must* be submitted under
|the current license of that file. Any new files *must* clearly
|indicate which license they are provided under in the file header.
|Please verify that you are legally allowed and willing to submit your
|changes under the license covering each file *prior* to submitting
|your patch. It is virtually impossible to remove a patch once it
|has been applied and pushed out.
|(4) Review the Eclipse Due Diligence Process.
|(5) Sending your patches.
|"git format-patch" command follows the best current practice to
|format a commit as a reviewable text message.
|At the beginning of the patch should come your commit message,
|a line that consists of three dashes, followed by the diffstat
|information and the patch itself. If you are forwarding a patch
|from somebody else, optionally, at the beginning of the e-mail
|message just before the commit message starts, you can put a "From:
|" line to name that person.
|You often want to add additional explanation about the patch,
|other than the commit message itself. Place such "cover letter"
|material between the three dash lines and the diffstat, or please
|place it in the bug description itself.
|Open a new bug on the Eclipse bug tracker on the EGit project:
|Attach the mailbox file(s) created by "git format-patch" to the bug.