Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Gerrit
Here is more clarification on the pull source problem.
You are recommended to always pull from origin for obvious reasons(that's one for the rulebook). But it's also possible to pull from a Gerrit change and base your feature on top of it, in a new, separate Gerrit change. Now the change you depend upon evolves with new patches and is eventually submitted. You are now depending on an already old patchset. It will never be submitted to origin, because its evolved version already is. At this point when you try to submit your work this is what I was refering to as hell, when people just start over :-)

Also working in parallel with Gerrit is possible. There's a way to bypass it completely but that would be strange and you probably will have to sit down and get clarity on your usecases and their needs.

Best Regards
Bobby

On Wed, Nov 23, 2011 at 1:53 PM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
Thanks Bobby. Based on your comments, I think we'll wait for Gerrit to mature some, at Eclipse.org and generally.

I must admit, I expected to pull from origin and push to gerrit, so that committers are working with a stable reviewed version. All committers working from gerrit sounds like it will then only benefit the stability of 3rd parties who pull from origin.

I get the impression that it is not possible to work normally in parallel with gerrit, so it's a big risk given that we are motoring on several features right now.

I also personally dislike rebasing, although I know some people recommend it. Merge commits (a) avoid rewriting history once you have pushed a branch, and (b) a useful reminder of development steps when doing code archaeology (a not particularly pleasant, but sometimes necessary task).

Regards,
Glyn

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.

 

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


_______________________________________________
virgo-dev mailing list


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


Back to the top