This week's Git Tip of the Week is about using Eclipse with EGit. You can subscribe to the feed if you want to receive new instalments automatically.
(E)Git at Eclipse - a history
This post is about using EGit in Eclipse; if you are uninterested in Eclipse as a platform, feel free to come back next week.
EGit, and its library layer JGit, have been in development for a long time and this week will be shipped as version 1.0 with the Eclipse Indigo simultaneous release. This is the first time anything other than CVS has been shipped by default out of the box for an Eclipse download.
As well as being good news for Git, it's also great news for Eclipse. The transition towards DVCS has been a long road and yet EGit is just the beginning.
Originally, Eclipse shipped with just CVS, but whilst additional plugins were able to be used to access Subversion, none of them were shipped with the default package due to licensing issues. It also didn't help that there were two competing Subversion projects, Subclipse and Subversive, both of which needed additional binaries in order to work. (It really didn't help Subclipse's case that it didn't ship a pre-packaged OSX client, just as OSX was taking off as the de-facto development and conference-touting laptop.) Even now, Subclipse doesn't ship with drivers for 64-bit Windows as this becomes a more common platform.
The nail in the coffin for Eclipse's subversion usage ultimately was Git and GitHub. Whatever your personal preferences of (D)VCS are, there can be no doubt that GitHub has transformed the industry in adopting DVCS, and more specifically, Git. Not only that, but with Eclipse being swayed by Git, and Apache's read-only Git mirrors, it's clear that the majority of foundations are leaning towards Git support. (Google Code remains the outlier with Hg; in part, due to its implementation in Python – but in future, Google Code will support Git as well).
EGit is the set of Eclipse UI libraries that integrate with the Team providers, whilst it relies on a re-implementation of the core Git libraries in Java, JGit. As well as powering EGit, JGit also powers the runtime inside Gerrit, a popular review tool (which I've written about before), as well as a port to Android in the form of Agit.
One of JGit's advantages is that the Git on-disk format is both well documented and well understood. In fact, it's this on-disk format that has resulted in most of the additional libraries and tools being made available; instead of having to call out to a specific blessed library (like SVN and Hg do), a Git client is capable of creating its own tree from content in an existing Git repository. Pretty much every Git tool reads, processes and generates trees of objects and references to those.
Using EGit
Most of the Eclipse Indigo release packages already have EGit in place; but if not, it's a simple operation to go to the EGit entry on Eclipse Marketplace to download it into your client. Whilst Helios shipped with a 0.12 version in service release 2, Indigo ships with version 1.0 – although that can also be installed in a Helios runtime if you want to add the update site to your runtime.
There's a lot of good documentation on the EGit wiki that includes my Git for Eclipse Users, which gives a good background in Git for those who aren't aware. But there's also lots of screenshots to show you how to get things done as well.
Unlike CVS/SVN repositories, a Git repository will exist on your machine and your project will be hosted out of that. It's not recommended to create Git repositories under the workspace directory – Eclipse doesn't tend to like that. When you create a new Git repository (from the Git Repositories view, or from a newly shared project), it will default to putting it in ~/git. you can then create projects underneath that location, or share a project and choose that Git repository.
The other aspect to note is all projects in a Git repository share the same branch. If you have two projects, both on master, then if you switch branch on one project (say, to release37) then both projects branches will be changed. If you don't want that, you can create a clone of the Git repository locally, and remap the project to the local clone. However, this is likely to cause confusion if you do this normally.
Once you've shared your project (or imported it from a previously created git repository) then using it is much like any other team provider in Eclipse – you can commit, merge, branch, compare etc. as normal.
The only significant difference is that commit operations are local (i.e. affect your own local repository) rather than remote. So others won't see your changes unless you push them up. Similarly, if you want to get changes from others, you need to pull them down.
If you're using a Gerrit workflow, then it's worth enabling the (undocumented) gerrit.createchangeid flag, which enables the automatic creation of the Change-Id field. This is set if you clone from a Gerrit repository in the first place, but doesn't have an option to set it up afterwards.
If you're not using Gerrit, then having a clone with a pull policy set to 'rebase' is the most common one you'll find for emulation of the traditional workflows. You can configure this when cloning a project initially, but if not, you can set git config branch.autosetuprebase always, followed by configuring it for the branch(es) you have checked out with git config branch.name.rebase true.
The migration begins ...
Many projects have already moved to Git at Eclipse – the full list is at http://git.eclipse.org/c/, and major players like CDT and EclipseRT are in the process of joining other projects, like Virgo and ECF, who have already made the transition.
There are still some rough edges, both in EGit and also in the Git contributions policy, which are likely to be overcome by the end of the year. But having support out of the box for Git within all Eclipse runtimes, and the fact that projects are stepping up to move over to Git, means that the tooling will be under close scrutiny and improve over the coming months and years.
Come back next week for another instalment in the Git Tip of the Week series.