Projects Movin’ to Git/EGit

Over the past six months or so, I’ve monitored conversations concerning the migration of project code from CVS to Git in the dev-lists of several projects. Most developers, it seems, understand the value proposition of migrating, despite their concerns that with migration comes a whole lot of new learnin’ as they figure out how to say productive in the new environment.

Inevitably, discussion about the team provider for Git being developed by the EGit project becomes an prominent part of the conversation. “Is EGit ready for primetime?” is often the question that bounced around. And it’s an important question: resource-strapped projects have to worry about whether or not the tools they depend on are going to work for them.

Several times in these past six months, I’ve stepped into these conversations to remind projects that EGit–much like their own project–depends on early adopters to test and provide feedback. What’s even better than early adopters, is early adopters doing real work; Eclipse projects themselves are the ideal testing ground for a DVCS integration like EGit. Without that all-important feedback loop in full-swing, projects waiting for perfection may have to wait a lot longer.

I understand that you can’t make everybody’s problem your own. In the cases where I’ve stepped in, I have merely asked the projects to add this to their list of considerations. Maybe it’s a little unfair, but I also tend to ask something like “where would your project be without users and adopters?” Again, it’s just a consideration.

I have great hope for EGit 1.0. I haven’t installed the latest (0.11.0) yet, but have had a decent experience with 0.10.0. The project team seems to be providing quality quickly, and the feature set is filling in. I’m feeling very confident that we’ll be closing out Bug 293192 (quality team provider and tooling for Git). Bug 324116 (move the website from CVS to Git) won’t be very far behind.