2

Gerrit will merge potentially unreviewed changes that are earlier in the commit history and are in a different 'branch' of the repository. Here's an example:

  1. checkout gerrit branch devel
  2. create file1.txt, add, commit, push to refs/heads/temp_branch
  3. create file2.txt, add, commit, push to refs/for/devel to be code reviewed

When file2.txt is accepted and merged then file1.txt, because it's upstream and not in a separate change branch flagged as being under review, also gets merged in. This is potentially very problematic and the only solution I can come up with is to force every change pushed to every branch be code reviewed. This is not ideal, as you may want to have some branches with one group of approvers, or with no code review (for some code swapping?).

The solution here is to force every commit in the history be placed into code review, as would be the case had file1.txt not been pushed to a different branch in the same repository.

Is there a setting in Gerrit that imposes this rule? Can anyone think of a workflow that allows for the freedom to push to refs/heads/ without risking polluting other branches?

Many thanks.

mut1na
  • 795
  • 6
  • 21

1 Answers1

2

I suspect you are seeing this behavior because the commit in step 3 has step 2's commit as its parent. You can't submit a commit unless all of its parents have been submitted. I agree with you that this seems like a bug in Gerrit - it should refuse to submit until step 2 has been submitted.

Try this work-around - add step 2a after step 2:

2a. checkout the devel branch again

If the commits are going to 2 different branches, it doesn't make sense for them to be linear.

One other thought - what merge strategy are you using for this project? If it is cherry-pick, I'd try changing it to merge-if-needed, or if it isn't cherry-pick I'd try changing it to cherry-pick. I believe the behavior here is different between the merge strategies.

Brad
  • 5,492
  • 23
  • 34
  • Turns out that this flaw has been noted on the [Gerrit site](http://code.google.com/p/gerrit/issues/detail?id=1107&sort=priority&colspec=ID%20Type%20Stars%20Milestone%20Status%20Priority%20Owner%20Summary). Though you were right about the cherry-pick! I'm not sure if I trust cherry picks in terms of merge conflicts that could arise with multiple chained changes going through code review, and generally preserving the integrity of the commit history. But it does get around the issue of inadvertently merging unreviewed changes. – mut1na Feb 28 '12 at 22:02
  • just to add, the cherry-pick essentially makes the commit in the origin the 'official' commit id when it gets merged in. Also it means that you have to rebase on your origin branch for your own changes (though this will be trivial - i.e., no conflicts as you already have the code!), so your branch doesn't diverge from origin. – mut1na Feb 28 '12 at 22:24