Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Gerrit

My story begins a year ago. I was young git noob back then.

Just as it’s with every new thing you encounter you are eager to try it and get to its limits. Along with git there seemed to be a number of add-ons. Many visual tools to help you wrap your head around the swarm of branches and, interestingly, a code review tool called Gerrit. It promised to make your code reviews easier than ever and simplify your git experience. They were really exciting times and I had the luck to try the full package in a productive environment.

 

Nowadays I feel a little less noobier about git :-) and had close to an year of Gerrit experience.

I’ve seen many positives, like

  • just one-click submit after a successful review, 
  • out-of-the-box shared review responsibility among all committers, 
  • really fast turn-around for the unsuccessful reviews(it’s so easy to build on top of the previous patch and resubmit for a new review) 
  • and the ability to integrate with build voters that will validate the commit. 

On the other hand there are problems too, here are just some of them. 

  • To use Gerrit you need to add Change-Id attribute to your commit messages. No worries here – there’s a git hook that can do this automatically… but not for merges. So to stay out of trouble rebasing is the way to go. 
  • Displaying merge diffs need more work – sometimes these are empty(when merging two branches), on other occasions they don’t contain conflicting files.
  • The way Gerrit handles dependencies between changes feels unnatural. A specific characteristic of Gerrit is that it stays between your local git repository and the origin, acting as Purgatory. For some reason developers are allowed to build new changes on top of changes still in Gerrit(not submitted to origin). Now this is where your life can turn into hell. This is a problem people stumble into amazingly often(everyday). Such situations have many solutions but from experience I can assure you most people just start over, abandoning their previous effort.

I’m well aware most of these are simply usability issues and you can easily avoid them by following the recommended rulebook( + other rulebooks you may have), but it’s a fact this complicates devs’ lives without obvious need to.

 

Personally, I love my console git workflow(occasionally + SourceTree). It just works whatever I do. I know the simple things are simple to do, but I can also do complex ones if I need to. I can undo anything and don’t need a rulebook “just to be safe”. To me Gerrit is like a little mosquito in my calm git room. I can live with it but it’s a bit annoying.

 

Having said that I strongly believe Gerrit can one day deliver and actually make my workflow simpler and reviews easier, I just feel it isn’t there yet.

 

From Virgo perspective, if you think we can try Gerrit in the current state of the repos(moving them was mentioned?), we can try and see how it goes. But if it requires more serious effort I would vote we wait for now.

 

Best Regards

Bobby


On Wed, Nov 23, 2011 at 10:26 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
Based on https://bugs.eclipse.org/bugs/show_bug.cgi?id=283749#c92, if we do decide to git gerrit a go, perhaps we should move all the Virgo and Gemini Web repos at once. Thoughts?

Regards,
Glyn

On Wednesday, 23 November 2011 at 08:24, Glyn Normington wrote:

Gerrit is available on a limited, bleeding-edge basis:


Since we've discussed using gerrit in Virgo before, I'm inclined to volunteer the kernel as a trial repository. What do others thinks, particularly those with experience of Gerrit?

Regards,
Glyn

_______________________________________________
virgo-dev mailing list


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


Back to the top