Ekke's Indigo Highlights

EGit/JGit and Mercurial: DVCS in Indigo


Distributed Version Control Systems in Eclipse Indigo.

For many years, Eclipse projects have worked with CVS and SVN as version control system, and great Team Provider plugins made this easy.

What’s new in the Indigo Release (Eclipse 3.7)? Modern version control systems are distributed systems (DVCS) and now EGit/JGit version 1.0 has been release.


Eclipse Projects Will Switch to Git

The decision was made some time ago: in the near future, Git [2] will be the default VCS at Eclipse. EGit works perfectly together with JGit [3]. JGit is a pure Java implementation of Git and is hosted as a project at Eclipse – the same as EGit. EGit provides the Team Provider plugin and allows us to use Git functionality comfortably inside Eclipse. The committers of EGit and JGit worked hard to release version 1.0 together with Indigo.

Why use a DVCS (distributed Version Control System) ?

A DVCS is much more flexible:

  • developers have a local copy of the repository
  • you can work off-line
  • fast and easy branching
  • forks/clones allow safe read-write without being a Committer
  • commits are fast, so you can really commit in short intervals

You’ll find enough resources on the internet to understand how a DVCS works, so I don’t want to talk about this topic here.

Git and Mercurial

The most important DVCS are Git and Mercurial [4] (aka hg). There’s also a Team Provider plugin for Mercurial: MercurialEclipse. [5] Now, with the Indigo Release both plugins have nearly the same functionality and power. Git is something more complex and allows the user to solve more types of workflows. Exclusive to Git is a “staging” – state: a step between new files or changes and the commit itself. You can collect changes at stage before committing – so it’s something between “prepared to commit” and commit itself.

Also, Git can work perfectly together with Gerrit [6] – a Code Review System – allowing you to push changes at first to Gerrit, where commits have to be reviewed from one or more other committers. One of the reviewers can be a build system like Hudson/Jenkins, so you can be sure that the build runs well before pushing changes into the real, ‘master’ repository.

For some years I’ve been using MercurialEclipse without any problems and from my POV it’s easier to use than Git. But of course in one of my next projects I’ll use EGit 1.0, and compare both. If you want to place a project at EclipseLabs and also use a DVCS, you have to choose Mercurial, because EclipseLabs was hosted at Google Code, which provides Mercurial, but not Git.

There are many hosting systems for Git and Mercurial making it easy to try some things out: most important are GitHub and Bitbucket. SourceForge allows projects to use Git or Mercurial.

EGit and MercurialEclipse: the UI

If you’re using a central VCS there’s only the commit command to store changes into the central repository, whereas commit on a DVCS only stores changes into the local repository. You then have to execute Push to move changes into the remote repository, or Pull to get the changes from there.

Let’s take a look at some of the provided views and menus – at first the team-options-menu.



Both DVCS provide similar functionality, but the menus are ordered differently and also some of the used icons are different. If you are working with both systems at the same time it’s easy to click the wrong menu item.

“Serve” is an option only available for Mercurial: using an integrated webserver you can take a look into the local repositories using a browser. This allows it to be used by team members without having Eclipse installed.

EGit and MercurialEclipse are both providing a Repository View, but the structure is different. Some of the features where you have to use the Team-Options-Menu at MercurialEclipse are placed inside the repository View at EGit.



Both systems are providing a History View, where you can see in detail what happened. If everything is not visible, please take a look at the small toolbar icons inside the view – they switch functions on and off.



You see that both plugins have similar functionality – please also take a look at the preferences. For me it was no surprise, that No .1 in Ian Bull’s Top 10 list was: EGit/JGit. [7] As soon as version 1.0 was out, there were new projects available like gitBlit [8] and Chris Aniszczyk has just developed a new git-reflog View [9] – so work is going on to make it even better. It will be an interesting year to watch how more and more Eclipse projects switch to Git.




Mercurial and Git are both powerful and stable Version Control Systems and it’s easy to test both of them if you’re not sure which one best fits your needs.

The next (5th) part of my highlights will be on UI design – especially WindowBuilder. For many years I’ve been using SWTDesigner from Instantiations – Instantiations is now a part of Google, and Google have donated the sources to Eclipse – a great decision !

Check out part one part two and part three of Ekkehard Gentz’s Indigo Highlights, for even more info on the Eclipse release.

Ekkehard Gentz has worked as an Independent Software Architect for more then 30 years in the domain of business applications (ERP). Ekke's focus is on model driven development, OSGI applications and mobile Java Apps. Ekkehard is Committer at the Eclipse Riena Project and Project lead of Open Source Projects redView, redVoodo, enMOcs and red-open. ekke twitters at @ekkescorner and blogs at

Inline Feedbacks
View all comments