Gerrithub.io issue -- Pushing a change to gerrithub generated a review for every historical commit

[Dan Chow]

This happened 3 weeks ago inexplicably. Although I'd pushed changes no problem to gerrithub over the last month or so -- all the sudden this latest time something happened and it generated 300+ outgoing code-reviews. This blocked merge on the commits I needed to submit and when I tried to resolve the old commits -- given that some of them pointed to the old repository location -- it was ineffective.

I wasn't sure how to handle this so I recloned from gerrithub -- copied my changes over to there and pushed that it went through fine.

Fast forward to last week and when I tried to push more changes -- merge conflicts with the 300 historical reviews rotting in my dashboard raised issues again.

Stackoverflow says the solution here is to abandon the changes and rebase -- but given there is no bulk abandon -- this was taking forever.

I contacted gerrit support and they said:

"With regards to your high number of Gerrit Reviews generated, you have possibly pushed to “refs/for/master” instead of pushing directly to “master”. Instead of pushing the commits imported from the other repository, you have then generated one change under review for every commit imported.

It is (unluckily in your case) the expected behaviour in Gerrit: whenever you push to “refs/for/master” every commit pushed that is not preset in the remote target branch would generate a new review.

With regards to your second query:

So now I'm by hand abandoning each one and rebasing. Given that there was like 200-300 -- this is a very slow and manual process. The server seems to be having issues as well. So definitely, if this isn't the best way to handle it or there's someway to abandon in bulk, that'd be ideal :)

There is no “bulk abandon” command in Gerrit: the only thing you could do is to close all the reviews by pushing again to master and then, should you want to remove the commits, perform a force push to master of the “last well known ref SHA1” you would like to have on your target branch."

Given that all the guides I've encountered have said push to origin HEAD:refs/for/master -- I was curious about this mysterious workflow which involves correctly pushing to master.

Also hrm it's not clear to me why it thought that the old commits were not present in the remote branch.

Lastly, I'm pretty new to gerrit and github -- could anyone explain to me the process for pushing "again" to master and how to do a force push to master of "last well known ref SHA1" i would like to have on my target branch.

Thanks in advance :)

[Doug Kelly]

Hi Dan,

The advice you've been given is pretty much spot-on.  There's not much to expand on, other than there's two distinct cases going on (from what I can tell):

* Uploading a single (or set) of changes

* Synchronizing changes from one repository to another

In Gerrit, you always want to upload individual (or small sets) of changes to the refs/for/<branch> pseudo-ref. As you found out, this is what creates your review -- sometimes quite effectively. However, when you have a body of changes that have already existed and been reviewed, that's when you push to the refs/heads/<branch> ref -- in other words, you push directly to the branch, bypassing the review.

There's an added point I think Luca was mentioning: if you accidentally create hundreds of reviews, the only way to bulk-close them is to do a second push (of the same content) to "refs/heads/master" -- the result when you push directly to a branch after reviews exist is the open changes are automatically closed.  As he stated, at this point, if you wanted to undo the push entirely, a force push would allow you to "rewind" the branch to an earlier point in time, perhaps before any of those commits existed.  They would still be visible in the Gerrit change list as "merged" (if you closed the changes by pushing to refs/heads/master) -- but they would no longer be visible in the tree.

I've not worked with GerritHub much, but most likely, something was causing the synchronization to not happen (however that's supposed to work), and so the changes were in your repository, but not in Gerrit.

Hopefully this at least gives a bit more explanation on the "how to deal with it" aspect. :) Also, you're not alone. I've seen someone open several hundred reviews (even as much as a thousand) on a single project more than once -- and had to deal with the hundreds of emails generated as a result.

[Dan Chow]

Excellent, thanks so much for clarifying Doug! This is really helpful. I think it's been a challenge to piece together the flow since there are a lot of moving parts and I'm unfamiliar with all of them (github/gerrit/gerrithub) ;p.

I haven't seen a guide that's gone over refs/for/<branch> vs refs/heads/<branch> flow -- Luca pointed me towards one I hadn't read before so going through it in detail, but if you happen to know of one handy let me know :)

Btw, if you are willing, could you give me a 2 second run down of how you guys do branching with gerrit? Most quick intro I've seen have only covered refs/for/master -- and haven't really explained the relationship between branches in gerrit vs your git repo/branches.

Do you make a gerrit branch each time you make a change? Push a review to that branch and when its submitted gerrit automatically merges it into the github master repo? Do you have to set up remotes or projects in gerrithub to make sure replication works properly. 

We had been pushing all our changes to refs/for/master and it'd been working fine until the hundreds of reviews :) But very much interested into heading towards a more standard set up :)

Thanks again -- without your clarification on pushing to heads on bulk closing :) I had manually abandoned ~100 yesterday in advance of a rebase -- but then gerrithub servers started dying repeatedly so it became a much more painful process for the remainder 200. Fortunately if I can leverage your pro tips effectively I might be saved from the horror and the pain ;p

[Doug Kelly]

On Wednesday, April 15, 2015 at 11:33:57 AM UTC-5, Dan Chow wrote:

Excellent, thanks so much for clarifying Doug! This is really helpful. I think it's been a challenge to piece together the flow since there are a lot of moving parts and I'm unfamiliar with all of them (github/gerrit/gerrithub) ;p.

I haven't seen a guide that's gone over refs/for/<branch> vs refs/heads/<branch> flow -- Luca pointed me towards one I hadn't read before so going through it in detail, but if you happen to know of one handy let me know :)

Btw, if you are willing, could you give me a 2 second run down of how you guys do branching with gerrit? Most quick intro I've seen have only covered refs/for/master -- and haven't really explained the relationship between branches in gerrit vs your git repo/branches.

I'll try.  Much of what I do is simply the legacy that was left by my predecessor (not that it's bad).  Also, we have some unusual branching concepts, so a lot of what I say here probably won't apply. :)

  

Do you make a gerrit branch each time you make a change? Push a review to that branch and when its submitted gerrit automatically merges it into the github master repo? Do you have to set up remotes or projects in gerrithub to make sure replication works properly. 

No.  Remember, we don't use GerritHub, or Github at all internally.  Gerrit is our one and definitive repository source.  That said, we use a number of systems globally distributed with the Gerrit replication plugin.  Each one of our mirrors receives push replication from the master -- but this also means that users can only clone from the mirrors -- never push.  Locally, many developers use whatever strategy is necessary for tracking their changes, then merge into either master or perhaps a feature or production branch, if it's warranted.  Some developers prefer keeping a single branch per change, others are more relaxed about it (obviously, we enforce neither).  When it comes to pushing to Gerrit, only certain users have branch creation rights, so most users work on an existing branch.  For features that are expected to be complicated, we may create a new branch, but if it's a simple bug fix, we may just use the existing branches.  Also, when a new product release is being made, we set a branch at the point of the release as a way to stabilize code.

There's some exception to this (I've not described everything we do in our role-based scheme), but that's the key concepts from it at least.

 

We had been pushing all our changes to refs/for/master and it'd been working fine until the hundreds of reviews :) But very much interested into heading towards a more standard set up :)

Thanks again -- without your clarification on pushing to heads on bulk closing :) I had manually abandoned ~100 yesterday in advance of a rebase -- but then gerrithub servers started dying repeatedly so it became a much more painful process for the remainder 200. Fortunately if I can leverage your pro tips effectively I might be saved from the horror and the pain ;p

I'm not sure there's any magic secrets that we have.   In fact, there's a number of existing papers on effective branching strategies (such as the git-flow paper).

Good luck!

[Dan Chow]

Thanks Doug :)