EGit and JGit have Java 7.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 3.8.2 (Juno)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

EGit and JGit have Java 7.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 3.8.2 (Juno)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

−

We are using ''PDE/API Tools Environment Descriptions'' (see changes for [https://git.eclipse.org/r/#/c/4785/ JGit] and [https://git.eclipse.org/r/#/c/4365/ EGit]) to facilitate detecting code which isn't working on Java 7. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''PDE/API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].

+

We are using ''API Tools Environment Descriptions'' (see changes for [https://git.eclipse.org/r/#/c/4785/ JGit] and [https://git.eclipse.org/r/#/c/4365/ EGit]) to facilitate detecting code which isn't working on Java 7. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].

EGit PDE Tools

EGit also provides tools for integrating with PDE Build and Eclipse RelEng Tools. If you are an Eclipse developer using PDE Build and/or the Eclipse RelEng tools you might be interesting in the following as well. Otherwise you might just skip this section.

In addition to the dependencies required for JGit and EGit you also need Eclipse PDE (>= 3.6.1) as well as org.eclipse.releng.tools in your target platform or checked out from Git in your workspaces.

Development IDE Configuration

Download and install the Eclipse package "Eclipse IDE for Eclipse Committers" or "Eclipse for RCP and RAP Developers" from here, if you don't already have it:

Tools

Note: You have to use at least Eclipse 4.3.2 (Kepler SR2), earlier versions had a bug where the following did not work (see bug 409073).

To install all the necessary tools to work on EGit/JGit, there is a egit-developer-tools.p2f file which you can use as follows:

File > Import > Install > Install Software Items from File

Browse...

Go to the location of your egit repository, open the tools directory and select egit-developer-tools.p2f

Alternatively, if you only want to contribute to JGit, download the file from the above link and select it

All the items you don't already have should be selected automatically

Finish the wizard

Restart

Java Requirements

EGit and JGit have Java 7.0 and Eclipse Platform 3.8.2 (Juno) as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

We are using API Tools Environment Descriptions (see changes for JGit and EGit) to facilitate detecting code which isn't working on Java 7. If you followed the instructions in the Tools section above, the necessary descriptions should already be installed. Otherwise install API Tools Environment Descriptions from the release train repository, see Installing Execution Environment Descriptions.

Dependencies

After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies. There are a few ways to install these.

Option 1 (recommended): Use a Target Platform

This is the easiest method to install dependencies:

Open the org.eclipse.egit.target project

Choose the egit-<version>.target file matching the version of your Eclipse platform (e.g. 4.5 for Mars) and open it (this may take a while as it downloads the indexes of the p2 repositories the target platform refers to)

In the resulting editor, click on the Set as Target Platform link at the top right (this may also take a while since it downloads the dependencies)

After that, the workspace should build cleanly. If not, try Project > Clean... > All. If this also doesn't help open Preferences > Plug-In Development > Target Platform,
select the checked target platform and click "Reload..." this will flush PDE's bundle cache and re-download the artifacts listed in the target platform.

There are different target definitions, one for each version of Eclipse that EGit supports. The one you select will be the one that is started if you want to try out a feature or bug fix.

You can always switch between them to test on different Eclipse versions. E.g. when you are developing some major UI functionality, you should try it with the oldest supported Eclipse release to make sure it doesn't depend on API that is only available in later versions.

Option 2: Install from Orbit P2 Repository

Install the dependencies from the Orbit p2 repository by importing the p2f file described above.

If you want to try another Orbit p2 repository version on the Orbit Downloads page, click on the newest recommended build (R-Build) and copy the update site link from "Orbit Build Repository" (it should end with /repository). Add this update site in Eclipse using "Install New Software..." and then find and select the following entries:

Java Mocking and Stubbing Framework

Args4j

Protocol Buffers

Apache Jakarta log4j Plug-in

Apache Commons Compress

XZ Data Compression

Hamcrest Library of Matchers

JavaEWAH

Running

Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:

Right click on the org.eclipse.egit.ui project

Debug As > Eclipse Application

This should create a new launch configuration and start a new nested Eclipse instance in debug mode. The created launch configuration can be edited, e.g. to change where the workspace of the nested Eclipse should be located.

The launch configuration can also be used in normal (non-debug) mode of course.

Mailing Lists

Maven Build Sequence

Due to a current limitation of Tycho it is not possible to mix pom-first and manifest-first builds in the same reactor build hence the pom-first JGit build has to run separately before the build for the manifest-first JGit packaging project.

The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.

The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes
that egit and jgit source trees are located under a common parent folder. If this is not the case the path
to the jgit p2 repository has to be injected via system property:

If you wan to build EGit for the specific Juno platform, consider using the platform-juno maven profile:

[~/src/egit] $ mvn -P platform-juno clean install

For EGit version 3.0, platform-juno (Eclipse 4.2) and platform-kepler (Eclipse 4.3) are available. In addition platform-kepler-staging refers to the Kepler staging repository.

Upon a successful build, a p2 update site should be generated inside egit/org.eclipse.egit.repository/target/repository. If not, make sure the target platform has been downloaded from within Eclipse (Windows>Preferences>Plug-in Development>Target Platform). The default target platform defined in the maven build is currently Eclipse 4.3.

FindBugs and PMD

As part of the build, JGit and EGit run FindBugs and PMD to find issues.

Checking for JGit API Changes using API Baseline

The JGit projects have API tooling enabled. In order to use PDE API tools to get assistance with maintaining API changes and additions you need to set an API baseline:

download the p2 repository for the latest EGit release (which includes the JGit artifacts) to a local folder, e.g. ~/egit-releases/updates-4.0, find the p2 repository URLs here and download the p2 repository of the latest minor release (service releases don't change API) using the corresponding link in the last column of that table

in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.0) and point it to the local copy of the corresponding EGit p2 repository.

the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems

To deploy the site from EGit HIPP (Hudson) at https://hudson.eclipse.org/egit/ enable the Maven profile build-server and add the Maven goals site:site site:deploy.

If you uploaded the site for a new release update the index
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html
to refer to the new release's site.

EGit

The EGit project sources its documentation from the wiki and generates Eclipse help content from it (under the covers, we are using Mylyn WikiText to make this possible). This significantly lowers the barrier for people to contribute documentation to the EGit project. To contribute documentation, simply modify the EGit User's Guide. Have a look at the Style Guidelines and Eclipse Documentation Style Guide to get some guidance on how to write good documentation. More on that can be found here.

The documentation is contained in the org.eclipse.egit.doc plug-in. The build-help.xml drives the generation of the help content. It is integrated into the maven build. The regular maven build of org.eclipse.egit.doc

$ mvn clean install

will only package the help content committed to the egit repository. To update the help content by downloading the latest documentation from the wiki run

$ mvn clean install -Dupdate.egit.doc

Don't forget to check all the generated help pages and especially all hyperlinks and images before pushing the updated help to the code review system for inclusion into the continuous build.

The aim is to generate new documentation every month or so (or just on demand). If you're making big changes or want the documentation refreshed, please let us know on the egit-dev mailing list.

Tests

JGit Unit Tests

The JGit unit tests are executed during the maven build.
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.

JGit HTTP Tests

The JGit HTTP tests in org.eclipse.jgit.http.test rely on the Jetty web container.

To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in dependencies.

Auxilary testing tools

Any code, including testing code, does not always do what you expected it to. The most common failure is probably the failure to actually execute the part of the code you wanted to test. Code coverage tools like EclEmma can easily visualize what part of the code is being executed.

Bugs

If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":

To get notified of bugs, go to your e-mail preferences and add <product>.<component>-inbox@eclipse.org to your watch list. For example to get notified of EGit UI bugs, add egit.ui-inbox@eclipse.org.

Keywords

To simplify bug management we started to tag EGit bugs with additional pseudo keywords (not normal Bugzilla keywords). The tags are prepended to the bug's summary field. Since we use these tags for internal bug management reporters of a bug should not add any pseudo keywords when filing the bug. The owner of the component bucket is responsible to add the keywords.

Keywords are used to group bugs without assigning them to a developer. So with the introduction of the keywords it is easy to search for all bugs belonging to a specific sub component. For example to get an overview of all open refactoring issues search for new, assigned or reopened bugs containing the word [refactoring] in the summary field.

Be aware that not all bugs are tagged with keywords, only bugs that belong to a certain sub group may have a tag attached. The following lists some of the currently used tags.

A single line summary in the comment field, followed by a more detailed descriptive paragraph;

Your credentials (email address) captured in the "Author" field; and

A "Signed-off-by" entry with matching credentials in the comment.

The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the Certificate of Origin.

In addition ensure

that the contributed code is licensed under the project license (EPL for EGit and EDL for JGit). This is done by putting a copyright and license header into every new java file. See other existing project source files for the correct content.

With a valid CLA on file, the signed-off commit and the copyright and license header in place, we will be able to accept small patches (<1000 LoC) immediately. For larger patches, we will also have to create a contribution questionnaire for review by the Eclipse IP team, but this usually doesn't require additional actions from you.

To verify whether a contribution requires a CQ, use one of the following git commands to check:

If it's committed: git log --shortstat

If not committed: git diff --stat

These commands tell you the number of insertions(+), and deletions(-). If the total number of lines inserted (e.g. added) in a contribution is greater than 1000 (yes, this includes comments) then a CQ is required.

Using Gerrit with EGit:

Eclipse will look for your private key in the SSH2 Home location specified in the General>Network Connections>SSH2 Preference Page. If your id_rsa private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least com.jcraft.jsch 0.1.44 to make use of it.

The wizards "Import Projects from Git" and "Clone Git Repository" will offer the possibility to browse the list of repositories on Gerrit servers and to clone selected repositories. After cloning the Gerrit configuration will be done automatically.

Importing Gerrit changes as Mylyn tasks

Fetching patch sets directly from the task editor

Reviewing changes in the task editor

Submitting changes from the task editor

Granularity of Changes

Make small commits, as small as reasonable. This makes them easy to review.

Each commit should have a commit message that explains very clearly what the commit sets out to achieve (unless this is abundantly clear from the code itself, which is basically only the case for trivial patches). Also, when you fix a bug then report which bug you fix. When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.

Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. The purpose of the commit is clear and can be understood easily by the reviewers and yourself.

Do not break the build and tests for any commit: this is very important for bug hunting.

Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.

A series of commits should work towards a 'feature' in a clear way and only 'enable' the feature in the last commit of the series.

In a series of commits first lay the groundwork and then build on that towards the feature.

Branches

When working with Gerrit, you can create local branches as you wish. When you are ready to push your changes, only the commits from your branch are pushed and are converted to reviews on Gerrit. The branch name itself is not visible on Gerrit.

Do not mix unrelated changes in branches: When you encounter a bug while working on something then create a new branch to fix the bug. Make sure you base it on the state of the remote branch that you want your fix to go to, e.g. origin/master. If you have other changes that depend on the bug being fixed then rebase your work on that new branch.

Merge/Rebase: If you want your branch to include new commits from the remote repository, rebase your local branch. The reason for this is that in Gerrit, changes are reviewed one commit at a time, and modified until all review feedback has been addressed. This is different from a pull request workflow, where the combined changes are reviewed and feedback is addressed with additional commits.

Coding standards

These documents have links to other document. Browse through them without expecting to learn everything, just so you know roughly what areas and types of details they covert. When you are
not sure about how to write a piece of code or design the user interface, these are the two
first places to look at.

In addition there is all the worlds collective knowledge on how to write programs that shine.
When there is a conflict, the Eclipse guide lines and conventions take precedence.

Breaking the rules is ok if there is a very good reason and you can tell us what that reason
is.

In addition to these general rules, we regard performance high. If the EGit plugin is slow
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a
lot of slow Java code.

Braces for one-line statements

Before 3.7.0 both in JGit and EGit, the preferred coding style was to leave off braces around statements with one line (with some exceptions to this rule), e.g.:

if (condition)
doSomething();

Starting with 3.7.0 braces are mandatory independently on the number of lines, without exceptions. The old code will remain as is, but the new changes should use the style below:

if (condition) {
doSomething();
}

The main reason to the change was to simplify the review process, coding guidelines and to make them more consistent with Eclipse code formatter, see bug 457592.

Removing trailing whitespace

In JGit and EGit we have enabled the save action "Remove trailing white spaces on all lines" for Java sources. This works except for empty comment lines, see bug 414421.

As a workaround, use the following sequence of commands in the Java editor to trick the save action:

remove the offending trailing whitespace

the save action re-adds the trailing whitespace

CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again

Another workaround is to use this little script from the command line to edit away trailing whitespace from changed lines.

Commit message guidelines

The commit message header should fit on one line and should start with an uppercase letter. A blank line separates it from the body of the message.

The first line should be a clear and concise description about the change and should not end with a dot.

Enter a newline before providing a more detailed description about the change.

Format the commit message to have newline characters after every 60-70 characters.

Commit message footers (everything following the last blank line in the commit message) in Key: value format are used for additional commit meta data. Some tools especially Gerrit parse this meta data to provide additional functionality.

If there is an associated bug number in Bugzilla about it, it should come as a Bug: footer right before Gerrit's Change-Id entry (if available) or towards the end.

If a Contribution Questionnaire has been issued to initiate and track the review of contributed changes by the Eclipse Foundation's IP team the IPZilla bug number should be added as CQ: footer in the format shown below

A Gerrit Change-Id footer is required for all changes pushed to Gerrit (to enable pushing new patchsets for the same change), it should be added in the format shown below. Use the Gerrit commit message hook or EGit to add the Change-Id.

A "Signed-off-by" can be added at the end of the commit message (see example below). Note: at the moment this is not required but may be used to list all who modified (amended, rebased, cherry-picked) this change.

Fix the commit dialog to respect the workbench's selection
Originally, the commit dialog would automatically check off all
files in the dialog. This behaviour contradicts a user's expectation
because their selection in the workbench is completely ignored. The
code has been corrected to only preselect what the user has actually
selected.
Bug: 12345
CQ: 6031
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
Signed-off-by: Your Name <your.email@example.org>

Copyright

When contributing patches, you have to update the copyright section at the beginning of the file if there is one. Please follow the style that is already present in the file. Some examples follow.

When there is only one copyright present (from a person or a company), like this:

Copyright (C) 2010, 2011 Some Name <some@example.org>

Change it like this (notice the updated year):

Copyright (C) 2010, YEAR Some Name <some@example.org> and others.

If there is a section Contributors: below the legal text and your change is more than a few lines, you can add your name there and optionally describe the change and link to a bug number. You can also start such a section if you contributed a significant change.

When there are multiple copyright entries there, add yours as a separate line. So, given this:

Copyright (C) 2010 Some Name <some@example.org>
Copyright (C) 2011 Other Name <other@example.org>

Add another line:

Copyright (C) 2010 Some Name <some@example.org>
Copyright (C) 2011 Other Name <other@example.org>
Copyright (C) YEAR Your Name <you@example.org>

For new files, copy one of the existing headers and start the copyright section with your name.

Test before submitting

Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 7 and Eclipse 3.8.2. You cannot use API's that are newer.

Sending patches by mail

Although sending patches by mail is the approved way of interacting with, and asking feedback from, the Git project, please don't send patches via git send-email. Instead, please use git format-patch to generate the mbox, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides.

If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.

However, it's generally preferred that you send items which you want comments on via Gerrit as per #Contributing_Patches, since Gerrit allows comments to be added in-line and allows the opportunity to send multiple versions of a patch after changes are made. Once a change has been submitted to Gerrit, you can then mail the developer mailing list with a request to review your change via URL or get Gerrit to send the mail on your behalf.

Gerrit Code Review Cheatsheet

Install the commit-msg hook in your repository

scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/

This will ask for a password. It is the password that you have to generate in the SSH Keys section of settings in your Gerrit account.

To update an existing change with a new commit

This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on change-id lines and replacing changes.

Note: To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).

To compare bulk diffs using Git

Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them.

If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, http://git.eclipse.org/r/2 shows the 'download' section for each patchset. In this case, it looks like:

Performing a git pull will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a git fetch instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again:

If you're doing this from within an already checked out project, you can do git fetch origin (or any other remote name in .git/config}.

Git fetched data will stay around in your repository, but will be 'orphaned' if no references point to it. To clean up, you can run git gc or wait until this happens automatically.

To trigger Hudson build for a change

We have build jobs jgit.gerrit, egit.gerrit and egit-github.gerrit on https://hudson.eclipse.org/egit/ which are triggered automatically when a new change or a new patchset for an existing change is pushed for review. These jobs will comment on the respective change when the build is started and when it's finished and vote on the change according to the build and test results.

Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.
Committers can manually trigger these jobs in the following way:

If you are not a committer and need to retrigger a build ask for that on the mailing list.

To approve a change

Click on Publish Comments

Vote with the radio buttons

To add a reviewer

Once you've pushed your commit to Gerrit for review, you can go to the web page (https://git.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.

It's usually not necessary to add any reviewers, it should be reviewed by the committers sooner or later. If this hasn't happened, you can look for people that did changes in the same area and add them as reviewers. It's also ok to comment on a change to "bump" its visibility.

Code Review

The code review category indicates your opinion on the quality of the code, and how well it fits within the purpose of the existing surrounding code. A +2 vote from any committer is required before submission can occur. A -2 vote from any committer will block submission.

IP Review

The IP review category indicates whether or not the change has been properly logged under the Eclipse IP Process. Under that process, any committer should mark his/her change +1 if they were the sole author of the change. For any other change, a committer should only mark +1 after ensuring the Legal Paperwork has been done. A +1 vote is required to submit a change, while a -1 vote will block submission.

Submission Guidelines

We strive to use Gerrit to improve our understanding of the code base and improve quality.

In order to ensure a proper review happens, some simple guidelines should be followed: