Jump to: navigation, search

Development Resources/Handling Git Contributions



Git does a great job of keeping track of author information, but there is no built in way to keep track of all the other stuff. At some point in the hopefully-not-too-distant-future, we'll be able to use Gerrit for this (see Bug 283749). In the meantime, we have to bridge the old world with the new.



    • e.g., I assert that I:
      1. authored 100% the content they are contributing
      2. have the rights to donate the content to Eclipse
      3. contribute the content under the EPL
  5. If required by the IP Due Diligence Process (e.g. if the contribution exceeds 250 lines), the committer creates a CQ (including the URL of the ref), attaches a patch, and waits for "check in" permission
    • In simple cases, pull requests can be merged into your local Git repositories as follows:
      • Add the contributor's Git repository as a remote, e.g. "git remote add <contributor-name> <contributor's repository URL>"
      • Fetch the latest from the contributor's repository: "git fetch <contributor-name>"
      • Cherry-pick the commit mentioned in the pull request: "git cherry-pick <hash of commit>"
      • Confirm that the generated commit has the correct content, and the correct metadata: "git show HEAD", "git log --pretty=full"
  8. Project committer closes the bug.

Note that the automated IP Log generator has been updated to include contributions made through Git (see bug 327594). If Git contributions have the author field correctly set, there is no need to mark the Bugzilla entry iplog+; in fact, doing so may result in redundant entries in the log.


The process changes a bit for projects that use Gerrit Code Review.


  • A user may have multiple email addresses registered with Gerrit; and
  • All of these addresses can be used to identify the user (generally via the Author Email field).


  1. Contributor must create an account on eclipse.org and agree to the Contributor Agreement;
  2. Contributor creates a Git commit:
    • If the contribution is associated with a Bugzilla record, cite that record in the commit message (e.g. Bug 12345); and
    • Author email address is set to a address registered to the author in Gerrit.
  3. Contributor pushes their commit to the Git/Gerrit repository;
  4. Contributor asserts on the corresponding bug or in a comment on the Gerrit push record that they:
    1. authored 100% the content they are contributing
    2. have the rights to donate the content to Eclipse
    3. contribute the content under the EPL
  5. Project committer works with contributor to revise (if necessary) the contribution and otherwise shape it into a form that can be accepted by the project;
  6. Required number of committers approve the commit (this may vary by project);
  7. Project committer initiated IP Due Diligence process:
    • If a CQ is required, the committer creates a CQ and attaches a patch generated from the Git commit;
    • Committer records CQ number in the commit message; and
    • When approved, committer reflects approval on the Gerrit record (i.e. they flip the IP bit on).
  8. Commit is merged into an appropriate branch by the committer


  • The IP Due diligence process permits for certain contributions for work done "under the supervision of the PMC". The definition of "under the supervision of the PMC" varies from PMC to PMC, but is generally accepted to mean that the work is within the scope of the project plan and/or the contribution is a patch for an existing bug/issue.
  • A contribution provided through Gerrit does not necessarily have a corresponding record in Bugzilla. If such a record does exist, it should be cited on in the commit message.
  • A this point in time, we require that the contributor explicitly consent to the Terms of Use when an account is created; we further require that the contributor assert the three questions with each contribution. Consent can be given either on the Bugzilla record (if one exists), or on a comment connected to the Gerrit push.