|Re: [virgo-dev] Gerrit|
On Wednesday, 23 November 2011 at 10:36, Borislav Kapukaranov wrote:
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.
BobbyOn 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?
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 mailing list