Gerrit revision workflow: merge conflicts and re-approval

Question

We are considering using Gerrit for the large project. At this point it would be interesting to know how people are dealing with merge conflicts of approved changes.

Imagine, that many changes of different size are pending revision simultaneously, and they are being reviewed and verified gradually. Since some of them might be modifying the same piece of code, the conflicts are inevitable. It is not a problem if "integrator" accepts patches manually in a simple workflow, small conflicts can be resolved on the way, but with Gerrit things are different. When the change has been reviewed and approved, in case of merge conflict, as I understand, it will need to be rebased by the author and pushed for revision again, in which case revision process starts again. In the relatively active projects, with more than 50 external contributor commits per week, this might turn into nightmare, if revision of the same patch might be required to be done several times due to merge rejection after each approval and submit, which seems to be not efficient.

Questions:

1. Am I correct that Gerrit is not a way forward for the large and active stuff where the large number of merge conflicts is expected?

2. Some merge conflicts can be trivial, is there a way to resolve them without the need of bothering author to recommit the change?

3. If the change needs to be backported to stable branch(es), I guess the separate change for each branch needs to be pushed for revision, even if the cherry-pick is clean.

General comments about your Gerrit workflow experience are also welcome.

Answer 1

1. Gerrit is used by some really massive projects, such as Android and the related bsp, kernel, etc repositories. These projects get way more than 50 external commits per week. I think Qualcomm will have several thousand commits in about that amount of time.

2. There is a setting in Gerrit to auto-merge trivial conflicts. This can be set per-repository. If this option is set, the change is merged in based on your submit strategy (cherry-pick, merge if necessary) after the change has been reviewed and verified and a user presses the 'Submit' button. The best documentation I could find for this is here http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options under the --use-content-merge option.

3. Yes that is typically how we do things. There are other options (bypassing review, merging branches, etc), but cherry-picking to the needed branches and reviewing works well.