Monday, March 7, 2011

eGit in practice

I like Git in theory. Distributed version control has many advantages over non-distributed including local branching, easier task switching, and easier offline work.  However, as an Eclipse user, I find it highly disruptive to drop down to the command line whenever I need to perform any git commands.  Despite its advantages, using git instead of CVS or SVN has felt like a big step backward because of its lack of Eclipse tooling.

Until now, I have only been using git occasionally, and so I could live with the inconvenience.  However, it looks like some of my major projects will be moving to git and so I need to figure out what to do.  I have been eagerly awaiting the eGit tooling to reach a reasonable level of maturity.  I decided to try it out and see how far along it is.


Install and setup



I installed eGit 0.11.3 from the public repository (http://download.eclipse.org/egit/updates) into my SpringSource Tool Suite.  And as expected, the Git Repository perspective was initially empty.  So far so good.

I thought I'd start by cloning the SpringIDE project.  Initially, I tried right clicking in the Git repositories view, and expected that I'd be able to pasted the repository URL directly.  That didn't work.  There is only one option: to paste an existing repository path:



Instead, I used the "clone repositories" command button.  I was able to do what I wanted to, but it was slightly less intuitive than I would have hoped.

Using eGit


After cloning, Git placed the entire repository on my hard drive, which is nice because checking out, exploring, and comparing is much faster than using a traditional VCS.  Performing these operations within Eclipse is just as speedy as doing things like comparing local history.  At this point, I was very impressed.

Then I made a single change to a file and things started going downhill.  After the change, I had to wait about 30 seconds for the '>' to appear in the package explorer next to the changed file (whereas with Subversive and the CVS tooling, this happens what seems like instantaneously):


Then I started playing around... I right-clicked on the file I had just changed and selected Assume unchanged.  Uh-oh!  ClassCastException.  Now, click Assume changed.  IOException.  Apparently, though something worked and I was able to continue with the commit and then view the commit in history.

Next problem: I moved back to the Git Repositories perspective, and I had lost all of the git repositories in the git repositories view.  Re-importing them would not work.  It looked more like the UI had crashed than any data had been lost:


I restarted Eclipse and everything seemed back to normal:


Despite its problems, eGit has a good UI.  The project is clearly following the Eclipse User Interface Guidelines, and I was able to easily transfer my familiarity with Eclipse's CVS and SVN tools to working with git.  This is a strong indicator to me that the project is headed in the right direction even if it is not quite there yet.

And so...


The basic features that I need exist, but after 20 minutes of using, I hit several obstacles.  None of them were insurmountable and the project is usable.  Despite this, I do expect that future releases will be significantly more solid.  I will likely be using eGit for my day to day work, but for now this will be largely for repository and history exploration, rather than for commit and branch management, which I'll probably use the command line for.



EDIT: I raised Bug 339158 and Bug 339159 to track some of the problems I found.

2 comments:

  1. Thanks for the suggestion. I'm going to try some other git clients. I'm hoping that some combination of eGit + external client will offer what I need. I'll put SmartGit on my list.

    ReplyDelete
  2. Thanks for the post. I've tried to use eGit at work, but I have to admit that I've uninstalled it and just use the standard msysgit tools now due to performance reasons.

    I'm working on a medium sized code base - around 250k semicolons, a 300MB git repo, which represents about 50k classes in 200 eclipse plugins (plus those in the targets). eGit just makes Eclipse too slow to use on our typical machines (core2 duo, 2GB ram, 7200 RPM disk).

    However, I suspect other version control plugins would also suffer on projects of this size - I know how painful (read: unusable) ClearCase is on this kind of codebase from bitter experience!

    How big are the codebases you've been using?

    ReplyDelete