|
|
|
Short Version:
|
|
|
|
|
|
|
|
- Make small logical changes.
|
|
|
|
- Provide a meaningful commit message.
|
|
|
|
|
|
|
|
- Review and follow the Eclipse Due Diligence Process
|
|
|
|
|
|
|
|
http://www.eclipse.org/projects/dev_process/ip-process-in-cartoons.php
|
|
|
|
http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
|
|
|
|
|
|
|
|
- Review and follow the current guidelines:
|
|
|
|
|
|
|
|
http://wiki.eclipse.org/EGit/Contributor_Guide
|
|
|
|
|
|
|
|
|
|
|
|
Long Version:
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
|
|
|
|
|
|
|
|
|
|
|
|
(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:
|
|
|
|
|
|
|
|
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit
|
|
|
|
|
|
|
|
Attach the mailbox file(s) created by "git format-patch" to the bug.
|
|
|
|
|