问题
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:
- checkout gerrit branch
devel - create file1.txt, add, commit, push to
refs/heads/temp_branch - create file2.txt, add, commit, push to
refs/for/develto 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.
回答1:
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.
来源：https://stackoverflow.com/questions/9473074/is-there-a-way-to-force-gerrit-to-have-all-commits-in-a-branch-be-push-to-code-r