Twitter github

EclipseCon 2010 – Understanding Git at Eclipse

Yesterday, Shawn Pearce (Google), Robin Rosenberg (Dewire) and Matthias Sohn (SAP) and I gave a talk at Eclipse about Understanding and Using Git at Eclipse.

I believe the tutorial was well received. Our goal was to introduce people to Git, JGit and EGit. We also talked about why Eclipse is moving to Git in the future. I believe we accomplished that on top of the message that there’s no free lunch to moving to Git at Eclipse. Heck, I don’t only want Eclipse to move to Git, I want other open source projects to do it. The license of JGit is liberal enough that other projects like Netbeans can embed it. Git simply empowers contributors in a way that’s not possible with centralized version control systems.

It will take time to get the tooling right and understand how much a distributed version control system like Git is the perfect fit for Eclipse. On top of that, we explained how the EGit and JGit projects leverage Gerrit to facilitate contributions and code reviews.

It’s my hope by the next Eclipse simultaneous release, we have a good amount of projects moved to Git and the tooling is top notch. The only way this will happen is if we admit to ourselves there’s no free lunch and provide feedback. I’m already impressed with what happened after the tutorial… we have people filing bugs and providing patches. This is what open source is all about.

If you still don’t get it, watch Linus’ tech talk about Git and read the Pro Git book.

  • Contemplating Git

    What do you mean by “there's no free lunch to moving to Git”? I'm used to “no free lunch” meaning “it may look good at first but you always end up paying for it in the end,” as in TANSTAAFL.

    I don't think you're trying to say that git is an expensive waste of time, but since it's the only phrase you've bolded in the entire post, clearly you were trying to make an important point.

  • What I mean is simply this. You can't get something for nothing. There are people in the Eclipse community that expect the Git tooling to be perfect out of the box. That's not the way it works. There has to be some pain up front so people use the tooling and provide feedback so we can polish it. I think people have been spoiled by the CVS tooling in Eclipse so they demand the same quality immediately from the Git tooling. I think that's unfair.

    Does that make sense?

  • Kim Moir

    I'd be interested in seeing some performance benchmarks wrt git vs other SCMs. It would be a good selling point to PMCs to show performance benefits. Currently with CVS, lock file contention causes timeouts and performance degradation. Also, it would be great to highlight features that only git offers compared to SVN and CVS. Andrew Overholt showed me how bisect works at EclipseCon which seems very enticing 🙂

  • Kim Moir

    I'd be interested in seeing some performance benchmarks wrt git vs other SCMs. It would be a good selling point to PMCs to show performance benefits. Currently with CVS, lock file contention causes timeouts and performance degradation. Also, it would be great to highlight features that only git offers compared to SVN and CVS. Andrew Overholt showed me how bisect works at EclipseCon which seems very enticing 🙂