gerrit push to a different branch than what my workspace was set to

[Jason Talley]

We are using git/gerrit for our source control. One of our devs recently pushed a commit just like always, but pushed to the wrong target branch (wrong being not the same base as he was working out of).

The devs workspace/repo was based on branch CF2, but when he pushed to Gerrit, he pushed to PLR. It /appears/ that the PLR branch was rebased to CF2 because 2 additional commits were magically inserted into PLR, causing a build failure. Had those commits not caused a failure, this would have gone unnoticed.

Looking back, you can see in the Depends section of Gerrit the branches are different, but typically the depends section is closed/folded if the dependency isn't an issue.

Is there any way to 'prevent' cross-pushing like this? From what I think I know about branching, the answer is no. And if not, is there anyway to have Gerrit enforce that the dependencies are on the same branch?

We are Gerrit 2.5. The project is set to Merge if necessary.

Also posted on SO (http://stackoverflow.com/questions/26550706/git-push-to-peer-branch). My google-foo wasn't enough to figure out how to search for this situation.

[Doug Kelly]

What you've described sounds vaguely like https://code.google.com/p/gerrit/issues/detail?id=1107 -- can you review and see if this is related to the issue you have?  It sounds like a bug, but if, for example, the developer pushed directly to a branch (and direct push is allowed), this could have been an intentional result.

I believe you're correct, there's nothing to prevent people from working on one branch and pushing to a completely different one that I'm aware of (I'm fairly certain that's in fact how Git is designed to operate, after all).  If it was an issue of someone incorrectly pushing to the wrong branch directly, at least that's preventable, but it still can result in hundreds of reviews being created at once (and what a pain that can be)...

Good luck! 

[Jason Talley]

Indeed that sounds like what we are experiencing.  There's quite a bit of traffic on the patches.  Perhaps it will be worked out in the near future.

In the mean time, do you know if we set the project to FF Only, would that prevent this issue?  And what would that mean with respect to changing behavior we are used to?

[Doug Kelly]

On Friday, October 24, 2014 4:39:38 PM UTC-5, Jason Talley wrote:

Indeed that sounds like what we are experiencing.  There's quite a bit of traffic on the patches.  Perhaps it will be worked out in the near future.

In the mean time, do you know if we set the project to FF Only, would that prevent this issue?  And what would that mean with respect to changing behavior we are used to?

I can't say I've tried, but due to the nature of the bug, it sounds like FF-Only would at least sidestep the bug in part, due to the way it appears the bug is triggered (identical changes automatically get merged, but with FF-Only, you wouldn't be able to merge an identical change, except in the case it was truly a fast-forward). FF-Only has another problem that will be requiring everyone always rebase patches on the latest tip of the branch, but if your teams are sufficiently small, that may not be too inconvenient.

We actually use the Cherry-Pick strategy which has not exhibited this issue as far as I'm aware...