Git for Committers
- 1 Background
- 2 Setting up git
- 3 Working with git
- 4 Git magic
- 5 Reference
- 6 TODO
- 7 Using the EGit integration
- 8 Known git repositories for Eclipse projects
- 9 Meetings and Resources
DVCS make cheap branches a first class concept. When everyone has their own branch / fork it's up to the VCS to make local changeset management easy and the merge process as painless as possible.
This guide illustrates how you might use git to increase productivity when developing Eclipse. Even committers with access to the centralized repository will benefit. After all a committer can't (shouldn't!) commit work-in-progress to a repo replied on by millions of users. git makes the process of tracking and merging upstream changes painless, and allows quick and easy patch regeneration for bugzilla review.
The guide does not aim to give an exhaustive overview of the commands and how they work. There is large body of existing documentation under #Reference.
- bug 257706 Host a git repository on Eclipse Foundation servers, support git as the repository of Eclipse projects
- bug 257706#c63 Mike M. on potential problems with git at the Foundation
- bug 249745 Eclipse Repository Best Practices
Setting up git
Has someone already imported the repository for you? If so clone or fork theirs! Creating the repository from scratch is straightforward, but beware the initial checkout is very time consuming. (It's also not very friendly to the Eclipse CVS servers; git has to reconstruct the individual commits and checkout each changeset individually...) (See #Known_git_repositories_for_Eclipse_projects).
Cloning a repository is as easy as:
e.g. git clone git://github.com/jamesblackburn/eclipse-core-resources-tests.git org.eclipse.core.tests.resources
Importing a repo
The process of creating a repository is the same whether you're an existing committer or not.
Tracking only your own changes
If you're only interested in your own changes and/or don't care about importing existing commit history from a legacy repository, you can just tell git to start tracking changes in a specific directory tree. Turn any directory into a versioned repository with the sequence:
Git will then start tracking changes from this point onwards.
Importing from CVS
git cvsimport -v -C eclipse-core-resources -d :pserver:firstname.lastname@example.org:/cvsroot/eclipse -r cvs org.eclipse.core.resources
This command creates a new git repository importing all the history, in this case, from the org.eclipse.core.resources repository.
This commands says: import the org.eclipse.core.resources module into a git repository in the directory (-C) eclipse-core-resources. The -r switch says to store the loaded repository data under the cvs remote. A remote is like a git branch except you never checkout a remote directly. You'll create your own branches based on remote versions. The remote branches must be kept clean for when you next fetch updates from the remote.
With that one command you now have a fully-fledged repository waiting for you. Take a look:
git branch -a will show all the branches -- you'll see this contains all the upstream branches, potentially a lot! You'll see that you're currently sitting in master which cvsimport has created for you tracking the cvs/master remote branch. git log shows you the full imported commit history on this branch.
git cvsimport -i -v -C eclipse-core-resources -d :pserver:email@example.com:/cvsroot/eclipse -r cvs org.eclipse.core.resources
To update your repository bringing in recent upstream changes , run the git cvsimport command again. You might want to pass the -i switch to cvsimport. This prevents git from automatically merging (pulling) changes from the remote's master into the branch you've currently checked out. If your working tree isn't clean, has diverged, or you've checked out a different branch such automatic merge may fail.
You can see changes made in a remote with git log <remote_name>/<branch_name>, and compare diffs with git diff. You can merge changes in, or if you haven't shared your branch with anyone else, rebase your branch.
Examples: Some scripts which track Eclipse/e4 core.resources and CDT are in a github repository take a look at the eclipse-sync directory and the sync.sh script. This cvsimports the projects from the Eclipse repository and pushes selected branhces (HEAD and 3_4) to github.
Working with git
Creating a topic branch
Generating patches for Bugzilla
Sharing changes with other git'ers
Git in 20 Commands http://www.kernel.org/pub/software/scm/git/docs/everyday.html
Git for Computer Scientists http://eagain.net/articles/git-for-computer-scientists/
Git Documentation home http://git-scm.com/documentation
When importing an existing repository
- How to set up a local git repository as a committer
- How to import from Eclipse CVS
- Any additional notes to that?
- Important Commandline Commands to push etc
- Something along the lines of Ketan's blog for Mercurial
- Known Issues and Gotchas
- Initially pulling from CVS into a repo puts HEAVY load on the Eclipse CVS server ... better clone an existing git repo if available (Can be used as a a form of a torrent, it is possible to pull from someone else I know, and sync with eclipse servers, they're all the same repositories after all)
Using the EGit integration
Contributing to EGit
If you want to get involved with EGit, please see our Google Code project site:
Known open issues are listed here, along with the clone URL for the Git repository containing the project's code. Loading it into Eclipse is as simple as importing the existing projects from the checked-out repository. Please see SUBMITTING_PATCHES in the top level directory for information on how to send contributions in.
Known git repositories for Eclipse projects
- Core Resources: http://github.com/jamesblackburn/eclipse-core-resources
- Core Resources Tests: http://github.com/jamesblackburn/eclipse-core-resources-tests
- UI IDE : http://github.com/jamesblackburn/eclipse-ui-ide