In Mars we will have hook support in EGit, so this allows to do validations for example, so let’s say if you install a pre-commit hook this might check for example if you follow the coding guide lines, if you have trailing white space or stuff like that, or if your files you are adding to the history are named with ASCII characters or not, to ensure portability. We did a new ignore implementation which is much faster than the old one, so you will recognize the difference if you are working with larger repositories and it’s also supporting new functionality, so we now support some more complicated patterns like double star pattern or negation patterns in the ignore. You will get some better integration for stashing, so we improved the stash support, so that you can more easily create a stash, see what’s inside a stash, this wasn’t available earlier and also apply a stash later on, get rid of it as soon as you don’t need it anymore. We dropped Java 5 and 6 support which makes it much easier to install JGit in the end, because we don’t need that optional stuff anymore and we can also make it easier for developers using JGit to use the API because for example there are quite some objects in JGit where you need to release the object if you don’t need it anymore, and now we support AutoClosable, so you can just use a try with resources statement and you don’t need to care about the clean up any more.
Alex: And presumably that Java 7 support is the baseline both for EGit and also the JGit runtime as well, so downstream developers building on top of JGit have the same baseline as well.
Starting with Mars it will be Java 7, there is no use of Java 8 features yet, but I guess this will come.
Alex: We were talking earlier about perhaps the platform adopting Java 8 sometime for Mars+1, and if that happens then of course it will allow everyone to use that.
It looks like the platform is moving to Java 7 with Mars and after that probably to Java 8.
Many projects are now using Gerrit because it makes it easier for contributors to participate in the development process because they can just push their change into review without fearing that they break something because a change in review isn’t directly affecting others. Typically a build job is started which is first verifying this change and then committers on the project will have a look into the change and see if it fits into the project, if it adds a useful feature, performance is ok and so on, and if the changes also done following the contribution guide which most of the projects have; and then based on the feedback from committers, the author, the contributor can learn how to best contribute to the project and come on speed and maybe become a committer later on.
I’m saying that it’s, I don’t know exactly the number, maybe 30-40 projects are using Gerrit, especially the platform now that took up and saw really the benefits of using Gerrit because they get much more contributions since then because it became easier to do contributions and it’s also good for the committers because they can spend their time on useful stuff compared to if you want to review a change which comes in through Bugzilla is much more work for the committers as well.
4. What is about the Gerrit workflow that makes it easier for committers?
The main difference to other workflows is that contributors can push to the Git server, to the Gerrit server, and Gerrit will automatically create a review branch, so you don’t have to do this manually like in other solutions and then build jobs can be triggered, those registered on the project also can get an email if they watch the project, so they get notified about the change. You can also query for changes if you only want to look at certain changes and then the committers will have to look into the change and decide if it’s good or not; usually is neither or nor, so they give some advice how to improve the change until they are happy with the change, so the contributor is iterating on this change until the committers are happy and then the change is submitted to the, typically to the master branch and helps the project to have new features.
Alex: And presumably this gives them a quick warning message if a commit breaks the build for example.
Yes, and first the build job will vote negatively on the change and you will also get notified by an email.
Alex: So a lot more people are familiar perhaps with the GitHub pull model rather than the Gerrit push model, I wonder if you can just summarize the differences for people who might be interested.
The main difference is that the core principle of the code review in Gerrit is that each change needs to be as good as possible, so each change is iterated and if you look at the GitHub pull model, the subject of a review is a branch, so user has a fork of the repository, create some feature branch where he implements a new feature, he can do any number of commits on that, and then when he thinks it’s good enough, he sends a pull request to the canonical repository where the maintainer sits and he can then decide is this branch good or not and often this ends up and ok, something needs to be improved so the contributor adds some more commits on top of the ones which are already on his feature branch which leads to pretty complex version history of the project in the end, because you see all the zig-zag what the contributor did until the committer was happy. Whereas if you look at Gerrit workflow each change is really reviewed and iterated until it’s good enough, so typically you end up with a cleaner history in the end.
If you are using GitHub workflow you will probably get non-compilable versions in between on this feature branch - hopefully the last one is OK, if the reviewer is taken seriously. Of course you could also implement a single change review using GitHub pull request but as far as I know most users of the pull requests, they look at branches, so it’s a less vigorous review process.
6. How is Gerrit evolving and scaling to meet the needs of thousands of users?
So our experience is pretty good, so we are using it in SAP as well, so we have in the meantime 12,000 users on a single server and we don’t have any problems with that. We are also now using it for customers in the cloud and they are looking into enabling that you can run Gerrit with more than one node which isn’t yet possible with the open source version and we hope that we can collaborate with others who are also keen to get this feature, so that you can really scale horizontally; at the moment we can only scale vertically.
What is in the works is support for git attributes, let’s see if we can finish that until March, that’s not yet sure. Another bigger change which is on the way driven by Obeo and Eclipse Source mainly is about adding support for merging EMF based models. There are many users which would be happy to get this. Let’s see, this is a quite big number of changes and some of them are pretty big, so it’s not so easy to review but we made our plans, so that hopefully we can get it in soon.
Over the last year we build a graphical UI for interactive rebase which really helps a lot, because it visualizes the interactive rebase, so compared to if you run an interactive rebase in native Git, you have to make, keep notes about the state in your mind, whereas with the new functionality in EGit you can really see what interactive rebase does. We also implemented at some short cuts, so that for example if you want to edit a commit which is, let’s say five commits down your history, you can simply select a commit and say edit this commit and then EGit will automatically configure an interactive rebase and immediately start it so that you can immediately start editing this commit, and when you are done you just commit amend and continue rebase and then you are done, so it’s a fast way to simply edit history. You can also use it to reword, just change the commit message if there is a typo that is also useful or if it turns out that some developers like to make many commits during development just to have snapshots where they can go back to if they are exploring different possibilities and then often it makes sense to later on squash some of the commits, so that reviewers for example don’t have to look at all these tiny steps, they are more interested in logical additions which make sense as a whole.
Alex: And we've also seen Git and JGit being used inside tooling like Eclipse Orion as well.
Yes, there are multiple applications which are using JGit, one of them is Gerrit itself so it’s using JGit to serve Git repositories. Another application is Orion which is kind of a workbench in web, and of course there developers also want to create commits look get history and so on, so the Orion tooling is also based on JGit and managers workspaces from other developers and to begin a cloud environment.
Alex: There have being relatively a few changes which have been quite as impactful as EGit and JGit and the Eclipse ecosystem. Matthias Sohn thank you very much!
Thanks a lot!