A few days ago some people mentioned to me that it’s great that the sources from my posts are open but they can’t install git on their machines due to security restrictions in their company. They aren’t even allowed to install egit as an Eclipse plug-in. But there is  good news. You don’t have to use git when you want to get sources from github. You can download every branch from every (public) github repository without git. When you browse to a repository you can simply press the download button on the right and download the latest version of the repository as zip or tar.gz. Is this simple? As I said, it’s a kick-ass platform

A git repository is a direct acyclic graph of commits.  Here is a very simple git repository.

In the EGit history view it would look like this:

Now, let’s assume that core and ui bugs (commits E and F) were not actually bugs, but rather controversial design decisions. And the the fixes broke other parts of the application.  After a quick meeting, someone suggests a new way of addressing the problems that will make everyone happy. One problem, they’re not sure if it will actually work.   Since they are using git, they checkout the code before the controversial bugs were addressed (Commit B) and they start hacking away.  Now here’s the crux of the problem: a branch is a linear set of commits, so where do these new commits live? The truth is, head is not actually visible from any branch now.  This is a detached head.

In the EGit history view you can see you have no head.

The good news is that you can quickly fix this problem by creating a new branch.  In egit, this is as simple as Team -> Switch To -> New Branch. Now, all these ‘detached commits’ will live on the new branch (new_idea).

You can now see the new commits (and new branch) in the EGit history view:

What if you accidentally  switched branches while you were on a detached head.  At this point, there is no way to access the commits because they are not attached to any branch. Luckily, git remembers all the commits, even the ones that happened while your head was detached.  Simply drop the command line and issue: git reflog

You can now see the missing commits.  If you return to Eclipse and use Navigate -> Open Git Commit you can open the commit 73df399

And directly create a branch from here

Another very common way to lose your head is to checkout a remote branch. Again, if you checkout a remote branch, immediately create a new local branch for your new commits; otherwise you’ll be working with a detached head.

There is more information about detached heads here.  Remember, don’t fight your tools, just git ‘er done.

Anyway, I started my first blog 5 years ago and used some horrible, long forgotten php software. For my other blogs and the EclipseSource blog, WordPress is used. WordPress is probably the winner when it comes to blogging software. It’s widely accepted and heavily used by thousands of bloggers. While I like WordPress a lot, it has some drawbacks. Currently I’m sitting in the train writing this post and what tool do I use? A simple Text Editor. When I arrive at my company I have to paste this post into our WordPress, do a little formatting and publish it. What I really miss in this workflow with the text editior is the history of the post.

As a developer I like trying out the new stuff. As a result I’ve been using Git for a while now and I’m quite happy with it. I’m also an Eclipse committer and the Eclipse IDE is my home. Thanks to my colleagues I’m quite quick with all the shortcuts in the IDE. So, using the IDE as my blog editor and Git as the version control system (aka. history) would feel quite natural to me. But, how can we do this?

Luckily there is GitHub, probably your choice also for a Git hosting service too. Anyone can create a public Git repository for free. In the same way as WordPress is the winner for blog systems, GitHub is the winner when it comes to Git hosting services. What is less well known is that GitHub provides another service called GitHub pages. With pages you can use a Git repository to publish web contents. All you need to do is create a Git repository with a special naming (your-username.github.com) and everything pushed to this repository will be published under http://your-username.github.com (also good for publishing p2 repositories).

What the GitHub folks have also implemented is a Jekyll integration. Jekyll is a blog system that transforms your articles using static templates. You can add a blog post by adding a text file. After writing your posts, all you have to do is push the files to your GitHub pages repository and GitHub automatically starts the Jekyll transformation to create the blog. Isn’t this awesome? You get a blog system with Git as a history and a web hoster for free – in one provider .

How does Eclipse come into the game? After cloning your repository to a local destination you can use linked workspace resources to edit the blog post in your IDE. All you have to do is create a new project and change the location to your Git repository root (see screenshot below).

After editing your posts you have the option to use EGit (the Eclipse Git Integration) to push your changes to GitHub (don’t forget to share the project). The only piece missing is an Eclipse Jekyll integration (GSoC Students where are you?). With this I mean, when I save or commit a local blog post, it would be nice if a Jekyll transformation could be triggered to provide a local preview of the blog. Currently I do this by executing a command on the shell.

I’ve decided already that when I have to create a new blog I will use this technique. If you are not convinced yet, check out these example blogs which use GitHub and Jekyll.

Who’s speaking at the Stammtisch?

• The first talk will be an introduction by Ralph Müller. If you know Ralph you also know that this will be very interesting and you will learn something new about the Eclipse Foundation.
• After Ralph, Matthias Sohn and Stefan Lay from SAP will start the technical talks with an overview of the EGit project. Egit is an Eclipse team provider for the popular git version control system. I had the opportunity to hear their talk in Mannheim a week ago -  it’s definitely worth to listening to.
• The third talk will be about p2, the Eclipse provisioning technology.  Ian Bull is coming all the way from Canada – so its a special chance to meet Ian live.
• The next speaker isn’t traveling thousands, but hundreds of kilometers to the Stammtisch. Peter Friese is travelling from Hamburg (Germany) to Karlsruhe and will provide a great talk about Xtext.
• Andreas Hoegger has agreed to present a very young Eclipse project called Scout. To get you familiar with this application framework Andreas will travel from Zürich (Switzerland) to Karlsruhe.
• Last but not least Benjamin Muskalla will hold the last talk. To round out the evening, he’ll speak about the integration of other Eclipse projects with RAP.

How much does it cost?

• Attending the talks is all for free.
• But I think the speakers will appreciate a frosty beverage donation after the Stammtisch.

What do you have to do to attend the Stammtisch?

• First of all you need to read the information on the EclipseSource Stammtisch website.
• After this you can add yourself to the doodle for the Stammtisch. Please let us know if you are coming. Only this makes it possible to organize the event well.

I think this will be a unique opportunity to see these talks in the casual atmosphere of a Stammtisch. Thanks in advance to all speakers for agreeing to participate and for making this evening possible. It’s a great honor to have you all in Karlsruhe.

After the talks we will all go over to a small Italian restaurant and talk about the topics over a frosty beverage. You are free to join this round and network with the speakers and audience. If you’re not able to attend the Stammtisch you also have a second chance. I think all of the speakers submitted a proposal for the Eclipse Summit Europe. You can attend this event by following the steps described here.

Looking forward to meeting you at the Stammtisch. I will also be there and try to answer questions about RAP

The first one was presented by Marcel Bruch. He talked about the Eclipse Code Recommenders project which he’s working on at TU Darmstadt. The basic idea behind this project is to provide a way to recommend code. He used the analogy of the Amazon online store. When you buy a book you always get a recommendation along the lines of, “People who bought this book also found this one interesting…”. The Code Recommenders does exactly the same just with code.  Watch the great screencast the Code Recommenders Team provides if you don’t want to take my word for it.

Another especially noteworthy demo for me was presented by Stefan Lay. He demo’d the Eclipse Git Team provider called EGit.  In addition to the tooling he presented Gerrit. Gerrit is an automated review tool for Git. The scenario he presented was to push some changes to a remote repository. The changes were caught by gerrit to be reviewed.   With those changes however, an automated build failed and gerrit sent an automated message that the changes couldn’t be applied because they broke the build. I think this will make the workflow much easier for code review and keeping the repository stable. The EGit project already uses Gerrit for their productive work.

To put it all in a nutshell it was a very cool DemoCamp with 120 attendees and nice buffet afterwards. At this point I want to thank Ralph Müller and the Foundation who organized a spontanous Eclipse Stammtisch after the DemoCamp. It was great to talk to all the guys individually. The bad thing about this is that the evening went by too fast. But there also a good thing. Most of those people will also attend the Eclipse Summit Europe in November and we can meet again.

Over the life of Eclipse (Jeff McAffer tells me that he’s been working on Eclipse since 1999) a lot has changed. Eclipse started its life inside OTI/IBM. In November 2001 the Eclipse Consortium was announced and Eclipse was released as ‘Open Source’. For the next few years Eclipse grew, but was still mostly supported by a few large companies. New projects were proposed, new committers came on board, and Eclipse became the dominate player in the IDE space.  But as the popularity of Eclipse grew, so did its diversification. Then in April 2010, David Carver noticed that the number of active individual committers (those not associated with any particular company) was tied with IBM for the top spot.

What does all this mean and what does this have to do with the Eclipse Helios release? Well, as Eclipse continues to diversify, the Eclipse foundation will need a software revision control system that supports this diversification. The Eclipse Helios release marks the beginning of this transformation. Number 2 on my Top 10 List is: Git Support at Eclipse.

Three important components make up the Git support at Eclipse: JGit, EGit and the Git Infrastructure. JGit is a pure Java library implementation of Git version control system. JGit is licensed under the EDL has a number of users, including the Netbeans Git support.

EGit is the Eclipse tooling, and is build on JGit. There is currently support for a number of Git features:

History view:

Repository View:

Patch Support:

The JGit / EGit team has excellent documentation and there is some great information on Git in general.  Git is being worked on by Matthias Sohn, Shawn Pearce, Chris Aniszczyk, Mathias Kinzler, Stefan Lay, Robin Rosenberg and Christian Halstrick.  However, a really big thank-you goes out to the past (and present) committer reps for bringing Git to Eclipse.  The initial Git contribution provided a number of unique licensing challenges that required unanimous approval from the Eclipse board of directors.  Git at Eclipse would not have been possible without their hard work.

In addition to the tool support, Eclipse.org has rolled out Git infrastructure for the community to make use of. There are Git mirrors for Eclipse projects and even Git repositories that some projects have started to migrate too. The big thank-you goes out to Denis Roy and Wayne Beaton for this.  Git really is the future of Eclipse, and if all goes as planned, Git will be on my Top 10 List again next year.

Here is the full list of the proposals that got accepted for 2010.
Improve Eclipse Git integration
Student: Dariusz Luksza
Mentor(s): Matthias Sohn

WAR deployment for RAP/Equinox based applications
Student: Holger Staudacher
Mentor(s): Ruediger Herrmann

Theme editor for RAP
Student: Benjamin Muskalla (IRC: benny`work)
Mentor(s): Ruediger Herrmann

Rich Editor For Wiki Markup
Student: Harshana Eranga Martin
Mentor(s): David Green

index based model compare match engine
Student: Stefan Leopold
Mentor(s): Cedric Brun

Restlet integration with Equinox
Student: Rajeev Sampath
Mentor(s): Bryan Hunt

C++ editor enhancements
Student: Tomasz Wesolowski
Mentor(s): Alena Laskavaia

DNS-SD based wide-area ECF discovery provider
Student: Markus Alexander Kuppe (IRC: lemmy)
Mentor(s): Scott Lewis

Hudson Integration for Mylyn
Student: Markus Knittig
Mentor(s): Steffen Pingel

Google Wave ECF provider
Student: Sebastian Schmidt (IRC: sebs)
Mentor(s): Mustafa Isik

Integrate GMF runtime with Mylyn task focused UI
Student: Yongming Luo
Mentor(s): Mariot Chauvin

Congratulations to all the students and a big kudos to the organizers and mentors for their choice. As every year, it is pretty difficult to dismiss so many other good proposals but there were only 11 slots available this year for Eclipse. Looking forward to a great summer!

Watertower by flamouroux

At the moment, the attendee list is still pretty empty but save yourself a seat while it’s not booked out – they only have 100 seats available. Topics this year include EGit, EclipseRT, Android and Roo. Do you think a cool topic is missing? Step up and give a demo about what you’re doing! I’m really looking forward to see more demos of how people use Eclipse as IDE or runtime.

Hope to see you there for another great DemoCamp and ad-hoc Stammtisch!

In the meantime, I’d like to highlight some additions that I recently did as a package maintainer of the RCP package. (If you don’t know what a package maintainer is you should consider joining my talk on Monday about ‘Building EPP packages‘.)

• git is becoming more and more popular at Eclipse and EGit is always one of the first plug-ins that I am installing whenever I unpack a new Eclipse milestone on my computer. The logical step: Include EGit in my RCP package because I think that I am not the only one who needs this tool.
• Another addition that I recently made is the RAP tooling. My daily work has changed and in the last months I am doing more RAP development than RCP development. I am not entirely sure if one needs both in one package, maybe RAP needs to go into its own package, but so far I think both technologies  complement each other. I am happy to get feedback – see bug 230357.
• Last but not least: The Marketplace Client (MPC) is included to allow early feedback – the developers of this nice tool need your feedback to bring it into the best possible shape for Helios!

Now let’s wait until the packages are available… and I need to go back preparing my EclipseCon slides.

Somehow Eclipse as a whole totally missed the SVN boat. Only in the last year has there been any uptake of Subversion within the Eclipse Foundation itself. And although there are two separate plugins (and by my count at least 3 different adapter libraries) it still doesn’t feel quite as solid as the CVS counterpart. But the writing is on the wall: CVS does not fulfill all the needs we expect from a contemporary source code management system. And while I have been a long-time fan of Subversion (atomic-commits and rename tracking, yay!) I still feel that maybe the time of centralized source control is over, especially in an open source environment. Doug Schaefer seems to agree. Distributed source control makes it much easier for potential contributors to get started. Experimental and “investigative” branches are easier to manage, and things like feature branches are more easily merged again. While it’s not all roses either (partial checkouts and IP-taints anyone?), but it does make the the development process quite a bit better. And isn’t that one of the main goals of the Eclipse Foundation?

So over the holiday I checked out (quite literally) the latest egit sources and played around with it a little. I must say that I came away quite impressed. Although there are still some features missing, the core looks very solid and usable.

The history of the egit project

Because the source for egit is openly available, it was very easy for me to “grok” the innards of the git system. My C is getting a little rusty these days, so a Java implementation made a much better reading experience for me. Debugging and Ctrl-clicking as well for that matter. With the core jgit library in hand, I even tried to implement a versioned POJO persistence store, but that’s a story for another time. What struck me most about git was the raw and brutal simplicity and the resulting elegance of its design. Believe it or not, but git only knows four different types of objects. Java’s “hello world” uses about that many! Another neat thing is the hash value that is calculated for virtually everything you do. When I first readabout this feature, I was quite skeptical to be honest: For starters, I don’t want to type 40 letter strings anytime I want to reference a revision and secondly, what about collisions? Well I worked out the math on that one, and what it comes down to is this: by the time I will create my first collision I will have been struck by lightning three times over and have survived the sun going supernova. And as for typing in those hashes, well you need it less than you would think and even then you usually only need the first few letters to make it unambiguous.

So kudos to the egit team for the great and continued work on this project. There even is an egit project proposal up. Although git support was postponed in the last board meeting, I still think this a step in the right direction and I’m looking forward to future developments.