- 1 List of Git repositories available
- 2 My Eclipse project wants to use Git
- 3 Migrating from CVS/SVN to Git
- 4 Committers new to Git
- 5 Connecting, cloning a repo
- 6 Committing and pushing
- 7 IP process implications of DVCS
- 8 Creating a new repository
- 9 Permanently deleting code from Git
- 10 Setting up ssh keys
- 11 Setting up https for pushing
- 12 Referencing git repositories on the wiki
- 13 External mirrors
- 14 You don't need Git to get code from repository
- 15 Gerrit Code Review
- 16 Errors in Cloning
- 17 Resources
- 18 Recommended Practices
List of Git repositories available
Please see to http://git.eclipse.org/. NOTE: please use the clone links at the bottom of the pages.. Do not clone from git.eclipse.org/c/
My Eclipse project wants to use Git
- New projects may choose Git as their repository in the New Project Provisioning Request.
- Existing projects may migrate to Git from SVN or CVS. Please see Git/Migrating to Git for more details.
Migrating from CVS/SVN to Git
Please see Git/Migrating to Git.
Committers new to Git
Before working on a Git repository, please:
- Read Git for Dummies
- Read The Git Parable
- Have the Git Guide handy
- Also, check out EGit
- Consider editing your Eclipse project website using Orion
Consider editing your Eclipse project website using OrionHub
- Note that anyone can commit to their repo, but only Eclipse committers can push their repo to git.eclipse.org
- DON'T FORGET to configure your git environment. The 'commit' record must contain either your Eclipse User ID, or the email address registered with the Eclipse Foundation.
git config --global user.email email@example.com git config --global user.name "John Doe"
- Note that the above will set this as the default user name and email address to use when writing commits. You can set user.name and password on a per repository basis.
git config user.email firstname.lastname@example.org git config user.name "John Doe"
This will set the username and email address on just the current git repository.
Connecting, cloning a repo
Please see the list of Git repositories (above).
git clone ssh://email@example.com/gitroot/project/repo git clone ssh://firstname.lastname@example.org:443/gitroot/project/repo (possible workaround if you are behind a firewall) git clone https://email@example.com/gitroot/project/repo (if enabled for your repository)
Committer access via https is disabled (and discouraged), but it is available. Please ask Webmaster if you absolutely need commit access over https. Before this try if option no.2 (proxy.eclipse.org on port 443) works for you.
Anonymous, read-only access:
git clone git://git.eclipse.org/gitroot/project/repo git clone http://git.eclipse.org/gitroot/project/repo
git clone ssh://firstname.lastname@example.org/gitroot/cdt/org.eclipse.cdt.git git clone git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git git clone http://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
Committing and pushing
IP process implications of DVCS
Due to our rigorous IP process, the Eclipse.org use-case for a DVCS is different than that of other Open Source organizations. For this reason, an update hook is installed and must remain in place on every Git repository to ensure a clean IP provenance.
The Eclipse update hook will examine the Committer entries of an incoming push. All the committer entries must be of committers on the project, or the push will fail. Furthermore, your committer ID, or the committer email address registered with your committer account at the Eclipse Foundation must be present in the Committer Email record. Here are some scenarios to help understand this restriction:
Scenario 1 Jane Contributor is Author of code. Commits to her local repo. Jane Contributer pushes (publishes) to a committer's local repo. Committer pushes code to git.eclipse.org will fail. Committer cannot push code to us from a non-committer.
Scenario 2 Jane Committer, known as email@example.com to the Eclipse Foundation, is Author of code. Commits to her local repo as firstname.lastname@example.org. Jane Committer pushes code to git.eclipse.org will fail. Eclipse.org does not recognize email@example.com.
Scenario 3 Jane Committer, on project B, is Author of code for Project A. Commits to her local repo. Jane Committer pushes (publishes) to a committer A's local repo. Committer A pushes code to git.eclipse.org will fail. Committer A cannot push code from a committer who is not on their project.
Scenario 4 Joe Contributor Authors code. Commits to his local repo. Joe Contributor attaches patch to Bugzilla. Committer applies patch to his local repo, commits to his local repo. Committer pushes code to git.eclipse.org will succeed. Committer can push their committed code to us, preserving the Author information in the transaction.
Scenario 5 Project Team A has 5 committers. All committers commit to local repo. Committer pushes code to git.eclipse.org will succeed. Committer can push their committed code, as well as commits performed by other project members.
Please see Handling Git Contributions for information on how to handle "pull" requests from non-committers.
Creating a new repository
Webmaster can create a new repository for you. Just open a bug against Eclipse Foundation > Community > Git. However, Eclipse committers with shell accounts can create new repositories:
For consistency, the name of the repository must end with .git.
To set the description of the repository as shown on http://git.eclipse.org/, use SFTP to copy the desired content to the file /gitroot/project/org.eclipse.repo.name.git/description.
Permanently deleting code from Git
If you are required to permanently remove code from a Git repository, please open a bug against Community/Git and Webmaster will do this for you.
Setting up ssh keys
To avoid having to type in your password for each interaction with the server when using git from the command line, we recommend using public key authentication. The easiest way to generate a key pair, and to upload your public key to git.eclipse.org, is to do so from within Eclipse. Please see this document for more details:
Or do it the manual way:
Generate a public/private key pair if you don't already have one on your own machine ssh firstname.lastname@example.org "mkdir .ssh; chmod 700 .ssh" scp ~/.ssh/id_rsa.pub [email@example.com:.ssh/authorized_keys
Setting up https for pushing
Please note: Git access via HTTPS is not enabled by default. Projects must explicitly request this feature via a bug.
Here is a sample .gitconfig file which is used for git push via https. It is expected to be into your user's system directory (e.g. for Windows Vista "C:\Users\dtenev\.gitconfig").
[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = https://firstname.lastname@example.org/gitroot/webtools/incubator/org.eclipse.webtools.incubator.sieditor.git [branch "master"] remote = origin merge = refs/heads/master [http] proxy = http://proxy:8080 [user] name = dtenev email = email@example.com
It is configured for the following git project (notice that you got the 'c' letter into the following path): https://git.eclipse.org/c/webtools/incubator/org.eclipse.webtools.incubator.sieditor.git/
Do notice few things:
- URL to the remote contains user's name. Git will require your password on git push execution.
- URL to the remote does not contain the 'c' letter from the https browse URL above.
You may be curious to see the bugzilla issue (https://bugs.eclipse.org/bugs/show_bug.cgi?id=326992) which enabled https push in git repository, and do lead to the above contents of .gitconfig file.
Referencing git repositories on the wiki
To include a reference to your Git repository on your wiki page, you can use the Git Link Template. This links to the web interface where readers can get an overview of the repository, browse the source code, and see some commit stats. Here is an example:
Git repositories hosted on eclipse.org are now mirrored at GitHub and Google Source.
See the Git/External Mirrors wiki page on Eclipsepedia for more information.
You don't need Git to get code from repository
As mentioned in bug 329841 you can use the cGit web interface to get code, if you just need the code, and do not need to clone the repository, say to prepare patches or commit changes back in to the main repository.
- This is useful for things like checking out test scripts, say to a hudson slave, there you just need the files to
start a larger test process, such as using Ant's get task to get a URL such as
- It can also be useful to refer to a single file for (temporary) reference or review, such as
Gerrit Code Review
If you want to add code review to your Git tool box then see Gerrit.
Errors in Cloning
If your project has requested HTTPS push access, and your are trying to clone(anonymously(via HTTP or GIT)) and receiving 'Corrupted object' warnings:
- Try to commit a change via ssh(or have another committer on your project do so)
- Ask your rel-eng to check the permissions on the object in the repo ( should be at least 444 )
If the ssh commit works, and the permissions are not ok then either file a bug, or send a note to Webmaster asking to have the default mask on your git repo repaired. See bug 363599 for details.
The following resources are recommended reading for anyone new to Git or patch-based distributed version control systems in general. Feel free to add links here to reading that you found to be useful.
- EGit/User Guide - describes the dialogs and commands that can be accessed for the EGit eclipse plugin
- Pro Git - a handy description of how git works and some of what git can do
- Git SCM - the main git site
- msysgit - A git client and bash shell for windows - might need some crlf flags set, not sure.
- Git workflows - a blog post about Git workflows
- The Git Parable - A document describing how Git works
- Subversion Re-education - A guide to the conceptual differences between revision based systems like Subversion/CVS and patch-based systems like Git/Mercurial.
- Git tutorial from Lars Vogel - Describes the usage of the Git command line
- EGit tutorial from Lars Vogel - Describes the usage of the EGit team provider
- Provide a description for your Git repository by editing the description file in the repository root. This description is used in a couple of different places to help the community understand the purpose of the repository. Keep the description concise (e.g. one line of prose).
- Provide a CONTRIBUTING file in the root of your Git repository. GitHub, for example, encourages this convention to help members of the community understand how to contribute to the project.
- TODO provide an example of this
- Please see Handling Git Contributions for further information.