Skip to content

Contributor Guide

Jump to bottom
Matthias Sohn edited this page Dec 3, 2024 · 7 revisions
Table of Contents

Communication

Channel JGit EGit
Developer Mailing List JGit developer mailing list EGit developer mailing list
Build Notices Mailing List JGit build notices mailing list EGit build notices mailing list
Reporting Bugs File new JGit bug File new EGit bug
User Forum EGit User Forum

Automated Developer Setup

The fastest developer setup for contributing to JGit/EGit is to use the Eclipse Installer and the EGit project setup to prepare an Eclipse IDE for JGit/EGit:

  • download and unpack the Eclipse Installer
  • start the Eclipse Installer
  • select the advanced mode

Image:Oomph-01-advanced-mode.png

  • if the right most icon in the bottom toolbar of the installer rotates, there is an update available for the installer, which should be installed before continuing
  • if you are behind a proxy, change the proxy settings from the toolbar at the bottom

Image:Oomph-01a-proxy-settings.png

  • on the product page select "Eclipse IDE for Eclipse Committers" and click "Next"

Image:Oomph-02-proxy-product-selection.png

  • on the project page select project "EGit" and click "Next"

Image:Oomph-03-project-egit.png

  • on Variables page accept default target platform, to fine tune variables click "Show all variables", click "Next"
  • on the Confirmation page click "Finish"

Image:Oomph-04-installer-progress.png

  • the installer installs the chosen IDE and starts it, as soon as the installer says "Press Finish to close the dialog" you can close the installer window
  • the newly installed IDE will automatically clone the JGit and EGit repositories and configure the workbench for JGit/EGit development. You can observe the setup progress in the toolbar, if necessary you can reopen the setup wizard by clicking its icon in the status bar

Image:Oomph-05-eclipse-progress.png

  • when the setup finished the IDE should looks similar to this

Image:Oomph-06-ide.png

If you want to improve the EGit project setup, check the setup file in tools/oomph/EGit.setup (in your newly cloned egit repository). You can find more information about Oomph at

Manual Developer Setup

Obtaining Sources

EGit and JGit are self hosted in Gerrit. We use GerritHub which combines Gerrit for code review and GitHub for authentication, browsing, wiki and issue tracking.

You can browse the repositories on their GitHub mirrors: EGit, JGit

or using the Gerrit gitiles plugin: EGit, JGit.

Repositories

To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed.

EGit

URL: https://eclipse.gerrithub.io/eclipse-egit/egit.git

This is the Git integration for Eclipse IDE, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.

JGit

URL: https://eclipse.gerrithub.io/eclipse-jgit/jgit.git

This is the Java implementation of Git used by EGit, for working with Git repositories.

EGit GitHub Integration

URL: https://eclipse.gerrithub.io/eclipse-egit/egit-github.git

Moved to Mylyn: EGit also provided tools for integrating with GitHub and Mylyn tasks. They were moved to Mylyn in Eclipse 2023-06, see mylyn.egit.

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:

https://www.eclipse.org/downloads/packages/

Tools

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

Since 7.0 EGit and JGit have Java 17 and Eclipse Platform 4.28 (2023-06) as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

Since 6.0 EGit and JGit have Java 11 and Eclipse Platform 4.17 (2020-09) 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 17. 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. Set a Target Platform to fix this

EGit-Target-Platforms.png

  • Open the org.eclipse.egit.target project
  • Choose the egit-.target file matching the version of your Eclipse platform (e.g. 4.21 for 2021-09) 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.

Running EGit from Eclipse

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.

Also see the reference on eclipse application launchers.

Builds

The central EGit and JGit builds run on the Jenkins build infrastructure provided by the Eclipse foundation.

Prerequisites for the Maven build are

JGit

  • JGit can be built using Maven or Bazel
  • use Java 17 to run the JGit build, it's compiled for Java 11 but Tycho 4.0 used to build OSGi artefacts requires Java 17
  • JGit packaging projects (Eclipse features and p2 repository) are built using Maven and Tycho.

EGit

  • EGit is built using Maven and Tycho.

Mailing Lists

If you're interested in following builds, please check out the following mailing lists:

Maven Build

To build JGit or EGit versions <= 5.12.0 maven must be run using Java 1.8. Ensure that environment variable JAVA_HOME points to a Java 1.8 installation.

EGit versions >= 5.12.1 and < 6.0.0 can be built with any Java >= 1.8, but the build uses maven toolchain definitions. To run a local EGit build for these versions (including the 'master' branch, i.e. EGit nightly), you need to have a local file ~/.m2/toolchains.xml providing at least a JDK toolchain definition for "JavaSE-1.8":

    <?xml version="1.0" encoding="UTF8"?>
    <toolchains>
       <toolchain>
          <type>jdk</type>
          <provides>
             <id>JavaSE-1.8</id>
             <version>1.8</version>
          </provides>
          <configuration>
             <jdkHome>/absolute/path/to/jdk1.8</jdkHome>
          </configuration>
       </toolchain>
       <toolchain>
          <type>jdk</type>
          <provides>
             <id>JavaSE-11</id>
             <version>11</version>
          </provides>
          <configuration>
             <jdkHome>/absolute/path/to/jdk11</jdkHome>
          </configuration>
       </toolchain>
    </toolchains>

The jdkHome directory is the one that contains the bin directory in which there is the java executable.

Also include a definition for a Java 11 toolchain as shown above.

  • EGit versions >= 6.0.0 require at least Java 11 to build, and require a Java 11 toolchain definition for running the tests.

  • EGit versions >= 6.6.0 require at least Java 17 to build, and require a Java 11 toolchain definition for running the tests.

  • JGit versions < 6.0.0 with maven require running maven with Java 1.8 in all cases.

  • JGit versions >= 6.0.0 with maven require running maven and compiling with at least Java 11.

  • JGit versions >= 6.6.0 with maven require running maven with at least Java 17.

  • Due to a 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 local maven builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.

  • To run the build behind a firewall follow https://maven.apache.org/guides/mini/guide-proxies.html

  • To run the JGit maven build on a case-insensitive file system, you might need to suppress javadoc generation if you get an error "class IO clashes with package of same name". Use mvn clean install -Dmaven.javadoc.skip=true instead of plain mvn clean install.

Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):

[~/src/jgit] $ mvn clean install
[INFO] Scanning for projects...

[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install
[INFO] Scanning for projects...

[~/src/jgit] $ cd ../egit

[~/src/egit] $ mvn clean install
[INFO] Scanning for projects...

[~/src/jgit] $ cd ../egit-github

[~/src/egit-github] $ mvn clean install
[INFO] Scanning for projects...

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:

[~/src/egit] $ mvn clean install -Djgit-site=`path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository

in the same way you can configure a custom path for the build of egit-github to the egit p2 repository

[~/src/egit-github] $ mvn clean install -Degit-site=/path/to/egit/org.eclipse.egit.repository/target/repository

The Jenkins build uses (for SNAPSHOT builds):

[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/

If you wan to build EGit for a specific Eclipse platform use the corresponding EGit target platform. For instance, to build for Eclipse 4.19 (2021-03), use the egit-4.19 target platform:

[~/src/egit] $ mvn -Dtarget-platform=egit-4.19 clean install`

See the contents of bundle org.eclipse.egit.target for the available target platforms.

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.26 (2022-12). If you skip setting the system property target-platform the target platform for Eclipse 4.26 will be used. EGit built with that target platform can run on any Eclipse >= 4.26. If you choose a higher target platform, the EGit produced may not run on Eclipses older than the target platform version.

Dependencies and License Check

We use the dash-licenses Maven plugin to check the license of 3rd party dependencies. See the Eclipse projects handbook.

On the master branch with the following changes the maven build is now running the license-check automatically

A summary of the check results is written to the target/dash/summary file. Dependencies which need to be vetted are marked as restricted in this file.

It will fail the build if any dependency needs to be vetted:

13:35:57  11:35:57 [INFO] --- license-tool-plugin:0.0.1-SNAPSHOT:license-check (license-check) @ egit-parent ---
13:36:10  11:36:09 [INFO] Querying Eclipse Foundation for license data for 299 items.
13:36:10  11:36:10 [INFO] Found 246 items.
13:36:10  11:36:10 [INFO] License information could not be automatically verified for the following content:
13:36:10  11:36:10 [INFO]
13:36:10  11:36:10 [INFO] p2/orbit/p2.eclipse.feature/org.eclipse.emf.ecore/2.23.0.v20200630-0516
13:36:10  11:36:10 [INFO]
13:36:10  11:36:10 [INFO] This content is either not correctly mapped by the system, or requires review.
13:36:10  11:36:10 [INFO] Summary file was written to: /home/jenkins/agent/workspace/egit.gerrit/repo/target/dash/summary
13:36:10  11:36:10 [ERROR] Dependency license check failed. Some dependencies need to be vetted.

If that happens run the build again locally and provide a gitlab token with scope "api" to automatically create review requests for the IP team:

mvn clean install -Ddash.iplab.token="<gitlab token>"

Then wait until these requests have been approved.

You can set the option dash.skip to skip the license check:

mvn clean install -Ddash.skip

JGit Bazel Build

Since Gerrit is built using Bazel a Bazel build was also implemented for JGit. This simplifies working on Gerrit features which also require changes in JGit.

bazelisk build :all
  • The following test labels are supported: api, attributes, dfs, diff, http, lfs, lfs-server, nls, notes, pack, patch, pgm, reftree, revplot, revwalk, storage, submodule, symlinks, transport, treewalk, util
  • To run all tests execute
bazelisk test //...
  • To run specific tests, using labels:
bazelisk test --test_tag_filters=api,dfs,revplot,treewalk //...
  • to rerun all tests ignoring cached test results execute
bazelisk test //... --cache_test_results=NO
  • to set number of concurrent test runs
bazelisk test //... --jobs=4
  • to debug a test run
bazelisk test --test_output=streamed --test_filter=`<fully qualified test method> <test target>

e.g.

bazelisk test --test_output=streamed --test_filter=org.eclipse.jgit.api.GitConstructionTest.testClose //org.eclipse.jgit.test:org_eclipse_jgit_api_GitConstructionTest
  • to configure loggers for test runs edit org.eclipse.jgit.test/tst-rsrc/simplelogger.properties, see the slf4j SimpleLogger documentation
  • to run tests repeatedly use
bazelisk test --runs_per_test=3 <test target>
bazelisk build --java_toolchain //tools:error_prone_warnings_toolchain :all

Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.

Updating build version

use the tools/version.sh script to update the build version in all build files, e.g.

./tools/version.sh --snapshot=6.8.0-SNAPSHOT

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-6.8, 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-6.8) 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
  • see the PDE API Tools User Guide for more details.

Signing and Publishing

EGit and JGit builds running on the JGit/EGit Jenkins instances are automatically signed (using the CBI eclipse-jarsigner-plugin) and published to

Creating a release

Use the tools/release.sh script to create a new release, e.g.

./tools/release.sh v6.1.0.202203080745-r
  • release versions have 5 parts major.minor.patch.buildTimestamp-qualifier
    • since 6.8 we use UTC timezone for the buildTimestamp part of the version number, earlier we used EST.
    • qualifier is m1, m2, ..., for milestones, rc1, rc2, ... for release candidates and r for releases
  • We sign release tags, follow Git Tools - Signing Your Work to set this up on your computer before creating the first release.
  • We create all milestones and releases on a dedicated stable branch to avoid interference with ongoing development on master. E.g. use the stable-6.1 branch for releasing 6.1.0 and subsequent patch releases like 6.1.1.
  • push the locally created release commit to eclipse.gerrithub.io for review
  • wait for the verification build to succeed until it votes +1 on the Verified label
  • review and submit the release change, then push the release tag to eclipse.gerrithub.io
  • the CI job will build the release version and deploy it to the Eclipse Maven repo at repo.eclipse.org

Release Notes

We create a release record for each release in the Eclipse project portal and publish release notes there. We use it to publish release notes.

New and Noteworthy

For major and minor releases (e.g. 6.0.0, 6.3.0) we create a New and Noteworthy page

Contribution to Release Train

We participate in the Eclipse simultaneous release and its schedule.

The release train contribution for JGit and EGit is maintained in the git repository

in the files

  • simrel.aggr
  • egit.aggrcon

Checkout the master branch and update the versions of jgit and egit to be contributed and the URL of the new version.

Download Server

  • milestones (version ends with -m1, -m2, -m3) and release candidates (version ends with -rc1) are deployed on the download server to
    • egit/staging/<tag name>
  • final releases (version ends with -r) are deployed to
    • egit/updates-<major version>.<minor version>[.<micro version>]
    • releases on the download server can be browsed here.
    • old releases are moved to the archive server
    • Committers can trigger archiving on this page.

All builds are deployed to Nexus.

Maven artefacts:

p2 repositories

JGit releases are also deployed to Maven central using Sonatype's OSS Nexus using scripts located in the jgit repository under tools/maven-central.

Open simrel.aggr using the CBI aggregator editor to edit these files. This editor knows the structure of these files and can check their validity.

Push the change and create a PR, review and submit it when the verification build job has validated it.

The release train build is coordinated on the cross-project-issues-dev mailing list.

Documentation

JGit

The JGit project generates a project report and javadocs using a Maven site. This Maven site is deployed to https://download.eclipse.org/jgit/site/$%7Bproject.version. E.g. https://download.eclipse.org/jgit/site/4.4.1.201607150455-r/

Generating the site:

mvn site:site

Staging the site locally under ./target/staging:

mvn site:stage

If you can connect to build.eclipse.org over ssh (ask webmaster if you are a committer and need ssh access) you can deploy a local build of the site:

mvn site:deploy

The site is deployed under https://download.eclipse.org/jgit/site/$%7Bproject.version}

To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:

`jgit.website` `username` `${user.home}/.ssh/id_rsa` `{``}` `664` `775`

Password encryption for Maven is described in https://maven.apache.org/guides/mini/guide-encryption.html

To deploy the site from JGit HIPP (Hudson) at https://hudson.eclipse.org/jgit/ 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.

EGit Core Tests

The EGit Core tests are executed during the maven build for the bundle org.eclipse.egit.core.test.

To run them from the Eclipse workbench use the launch configuration which is part of the sources of the test bundle org.eclipse.egit.core.test.

EGit UI Tests

The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.

You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":

Starting a UI test from Eclipse:

  • select the test class or test method
  • click Run As > SWTBot Test

Image:Start-swtbot-test.png

Do not touch the mouse or keyboard when the UI test is running since this may disturb the UI test by e.g. moving the current focus to another window.

During Maven Build

The tests are executed in the integration-test phase of the default Maven lifecycle.

If you want to skip execution of UI tests (only execute core tests):

mvn -P skip-ui-tests clean install

If you want to skip all tests:

mvn clean install -Dmaven.test.skip=true

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

Links

Filing Bugs

How to file bugs

File a bug

We moved issue tracking to GitHub. If a bug on https://bugs.eclipse.org is still relevant for you then open a new bug on GitHub.

File a bug for a vulnerability

If you discovered a vulnerability you want to report send an email to [email protected] or file an issue here. This will ensure that the discussion on the vulnerability is kept private between the reporter and the committer group until the project prepared a release fixing the vulnerability.

Website

The EGit and JGit websites are located in Git repositories which are hosted on GerritHub

EGit

  • File > Import > Git > Projects from Git
  • Select URL
  • in Repositories View on node "origin" click "Gerrit Configuration..." and select branch "master", then changes you push to upstream will end up in Gerrit for review and can be submitted there

JGit

  • File > Import > Git > Projects from Git
  • Select URL
  • in Repositories View on node "origin" click "Gerrit Configuration..." and select branch "master", then changes you push to upstream will end up in Gerrit for review and can be submitted there

Contributing Patches

Using Gerrit

EGit and JGit projects are using Gerrit Code Review for Git based patch submission and review.

Both projects accept contributions only via Gerrit. Please do not send patches by e-mail. Although both projects are mirrored to Github, EGit and JGit also cannot accept Github pull requests.

Migration from git.eclipse.org to eclipse.gerrithub.io

Since the Eclipse Foundation decided to deprecate their Gerrit server EGit and JGit migrated their repositories to GerritHub at https://eclipse.gerrithub.io. The migration to GerritHub was completed on Nov 21, 2023.

GerritHub combines Gerrit for code review and GitHub for authentication, issue tracking and browsing repositories.

User Account

  • In order to contribute you need an Eclipse user account on eclipse.org
    • On creation of a new account you must agree to the Contributor Agreement.
  • For login to GerritHub and GitHub you need a GitHub account.
    • Associate your GitHub username with your Eclipse Account
      • Edit your Eclipse account: login and click "Edit my account"
      • Set your GitHub username at the bottom of the page "Personal Information".
  • If you are a project committer you will get an invitation to join the project's GitHub organization
    • Modifications of Eclipse user accounts are replicated every 2-3 hours to GitHub, i.e. it could take a few hours to get this invitation
    • You can check in GitHub settings if you are a member of the project's GitHub organization

Login to GerritHub and OAuth access to GitHub

GerritHub uses github.com for authentication. Permissions are granted to GitHub teams which are configured by Eclipse Foundation in the GitHub organisations eclipse-egit and eclipse-jgit.

For that it needs an GitHub OAuth scope granting read access to GerritHub:

1. Login to https://eclipse.gerrithub.io by clicking "GitHub Sign-in"

Image:1-GerritHub-first-login.png

2. On the first login GerritHub requests authorization for read access to GitHub.

Image:2-Gerrithub-Github-request-access.png

  • Reviewer: Review other people's changes using only your e-mail identity
  • Contributor: Contribute and upload changes to JGit/EGit
  • ProjectCommitter: Contribute to JGit/EGit as a committer
  • EclipseStaff: Administrate Eclipse Foundation Projects, import new projects from GitHub to GerritHub

If you are an EGit/JGit committer or Eclipse Foundation administrator

  • Request "organisation access" for the GitHub organisation eclipse-egit / eclipse-jgit.
  • This request needs to be approved by an Eclipse Foundation administrator.
  • It grants GerritHub read access to your membership in GitHub teams of the organisation used to check your committer / administrator status.

All users need to click "Authorize gerritforge-ltd" which want to

  • participate in code review (contributors, committers)
  • contribute changes (contributors, committers)
  • administrate projects in eclipse.gerrithub.io (administrators)

The initial scope selection done at login is stored as a cookie.

You are redirected to https://eclipse.gerrithub.io

Image:3-Redirect-to-Gerrithub.png

If you are a committer or administrator you can check if access to github organisations was granted:

Image:4-open-Gerrit-groups.png

  • If the approval of your request takes too long open a ticket on the Eclipse helpdesk.

3. If you want to change your access scope

  • click "GitHub > Scope"

Image:5-Gerrithub-Github-Scope.png

  • and select the access scope you want to use on GerritHub.

Image:6-select-github-oauth-scope.png

4. Click "login" to authenticate.

Image:7-login-to-github.png

  • GitHub redirection after login may take up to 30 seconds to complete.
  • Be patient, just wait and do not refresh the page until you are redirected to eclipse.gerrithub.io.

Git over SSH

When accessing GerritHub over SSH from git or EGit

  • use your GitHub username
  • upload your public SSH key to your GitHub account here
  • Import the keys to GerritHub
  • Gerrit SSH URL: ssh://[email protected]:29418/eclipse-egit/egit
  • Find all the repositories here

Git over HTTPS

When accessing GerritHub over HTTPS from git or EGit

  • use your GitHub username and the Gerrit HTTP password which can be generated here
  • Gerrit HTTPS URL: https://@eclipse.gerrithub.io/a/eclipse-egit/egit
  • Find all the repositories here

SSH Keys

Legal Paperwork

Before your first contribution can be accepted, you need to electronically sign the Eclipse Contributor Agreement(ECA). The ECA is good for three years. Find more information in the ECA FAQ.

Minimally, all Git commits you contribute must have the following:

  • A single line summary in the comment field, followed by a more detailed descriptive paragraph;
  • Your credentials (email address) captured in the "Author" field
  • In addition ensure that the contributed code is licensed under the project license (EPL 2.0 for EGit and EDL 1.0 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 ECA on file 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.

Doing Code Reviews with Gerrit

Using Gerrit with git command line

  • Upload your patch from Git to the target project:

    git push origin HEAD:refs/for/master

  • Visit the GerritHub to start reviewing

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.

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).
  • 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 but 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 local 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

Eclipse has standards for how to write code.

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 .

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 .

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.

Use of the "final" modifier

New code uses the "final" modifier in the following circumstances1.

Always:

  • final fields: marking fields as final forces them to be initialized in the constructor or at declaration
  • final static fields: clearly communicates the intent
  • where necessary to use final variables in inner anonymous classes
  • for simple local constants, e.g. final int MAX_RETRIES = 5;

Optional:

  • final classes: use when appropriate, e.g. API restriction
  • final methods: similar to final classes

Never:

  • local variables: it clutters the code, and makes the code less readable. When copying old code to new location, finals should be removed
  • method parameters: similar to local variables

Commit message guidelines

  • The commit message subject should fit on one line, try to keep it shorter than 50 characters, at most 72. A blank line separates it from the body of the message.
  • The commit message subject should be a clear and concise description of the change. It is recommended to start with the modified subsystem, followed by a colon and a description starting with capital letter and without period at the end. For example: UploadPack: Use reachability checker to validate non-advertised wants
  • In case of release engineering tasks without bugzilla entries the commit message header may look like "[findbugs] Fix warning XYZ for String constructor". The prefix in brackets is an indication why this comes without a corresponding bug.
  • The commit message body follows after a newline providing a more detailed description of the change.
  • Format the commit message to have newline characters after every 60-70 characters.
  • Find more reasoning about commit message formatting in "A Note About Git Commit Messages"
  • Commit message trailers (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. You can use the git interpret-trailers command to add or parse trailer lines at the end of commit messages.
    • If there is an associated bug number in GitHub about it, it should be linked as a Bug: jgit-1234 or Bug: egit-134 trailer right before Gerrit's Change-Id trailer (if available) or towards the end. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.
    • A Gerrit Change-Id trailer 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). It may be used to list all who modified (amended, rebased, cherry-picked) this change. This trailer isn't mandatory anymore.
CommitDialog: 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: egit-12345
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
Signed-off-by: Your Name <[email protected]>

License Header

All new code files, including test code, must have a license header.

JGit is licensed under the Eclipse Distribution License which is a form of the BSD-3-Clause License. Use of this license was approved in a meeting of the board in Sep 2009.

The license and copyright header to be used for JGit is

/*
 * Copyright (c) YEAR CONTRIBUTOR[ and others]
 * 
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Distribution License v. 1.0 which is available at
 * https://www.eclipse.org/org/documents/edl-v10.php.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

EGit is licensed under the Eclipse Public License 2.0 and uses the license header

/*******************************************************************************
 * Copyright (c) YEAR CONTRIBUTOR[ and others.]
 *
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License 2.0
 * which accompanies this distribution, and is available at
 * https://www.eclipse.org/legal/epl-2.0/
 *
 * SPDX-License-Identifier: EPL-2.0`
 *******************************************************************************/

The license header is placed at the very beginning of a file; in Java files above the "package" line.

See https://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.

Copyright

Copyright statements take the form

Copyright (c) {year} {owner}.

The {year} is the year in which the content was created (e.g. “2004”).

The {owner} is the name of the copyright holder. If the content is subsequently modified and appended to by other copyright owners, the words "and others" are typically appended. So for example: "XYZ Corp." or "XYZ Corp. and others". The words "and others" are used to avoid having to list every copyright owner and because often, most of the content in the file was contributed by the initial copyright owner with subsequent modifications by others being smaller. However, especially if the number of copyright owners is small (e.g. two), they may all be listed in a single copyright statement (for example: "XYZ Corp., John Smith, and ABC Enterprises."). Alternatively, additional copyright holders may be added by including multiple copyright statements.

For more details see the Eclipse Project Handbook.

Test before submitting

  • Add automated tests for enhancements and bug fixes to ensure functional correctness and avoid regressions
  • Run all existing tests. It does not take very long.
  • Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 11 and Eclipse 4.26. You cannot use API's that are newer.

Gerrit Code Review Cheatsheet

Install the commit-msg hook in your repository

scp -p -P 29418 [email protected]: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.

You can alternatively download the file. The hook helps append a Change-Id trailer to your commit message.

EGit can also generate a Gerrit Change-Id into your commit message both manually or in an automated way.

To create a new change

git push origin HEAD:refs/for/master

To update an existing change with a new commit

Amend the commit you want to improve and push it for review again

git commit --amend
git push origin HEAD:refs/for/master

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 trailers and replacing changes.

Note: To be picked up by Gerrit, a Change-Id trailer 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 trailers. If your Change-Id trailer 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, https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/2 shows the 'download' section for each patchset. In this case, it looks like:

  • Patch Set 1 git pull origin refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)
  • Patch Set 2 git pull origin refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)
  • Patch Set 3 git pull origin refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)
  • Patch Set 4 git pull origin refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)

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:

git fetch origin refs/changes/02/2/3
git fetch origin refs/changes/02/2/4
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25
# or 
git diff d14cc6 43de8d

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.

Trigger Jenkins build for a change

We have build jobs jgit.gerrit on https://ci.eclipse.org/jgit/, and egit.gerrit and egit-github.gerrit on https://ci.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:

  • Go to Trigger a Gerrit event manually page
  • Search for a change you'd like to build
  • Select the patch set(s) you want to trigger
  • Press Trigger Selected button

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

To approve a change

  • Click "Reply"
  • Vote on the Submit Requirements

To add a reviewer

Once you've pushed your commit to Gerrit for review, you can go to the web page (https://eclipse.gerrithub.io) 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.

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:

  • vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;
  • If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know
  • let non-trivial changes be in review for at least 24 hours
  • if you want your changeset reviewed by someone, please add them as a reviewer

Tips & Tricks

Class Loading Issues

If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:

Enable tracing in your launch configuration to get information how imported packages are resolved at runtime. Select the Tracing tab in your launch configuration, select Enable tracing, select plug-in org.eclipse.osgi, select category resolver/wiring on the right side.

Clone this wiki locally