I\'m struggling to find a good workflow when two or more people are pushing patch-set\'s to the same change-set in Gerrit.
I am trying to accomplish this with comman
Your problem is gerrit
itself. A changeset in gerrit
is a single git
commit that's rewritten whenever the changeset is changed as a part of the review process. As such, you get a history like this:
reviewed branch head --- changeset A, first revision
\-- changeset A, second revision
\- changeset A, third revision
Now, with the workflow you sketched in your question, you attempt to create this history:
reviewed branch head --- changeset A, first revision --- changeset A, second revision
Any change that is present in both revisions will conflict with itself if you do this.
The gerrit
way to work around this is to fetch the latest revision of the changeset, amend the changeset, then push it as a new revision of the changeset, replacing the previous changeset, hoping that no other developer has worked on the same changeset in the meantime. The last part is where a gerrit
based workflow fails to achieve what is trivial to do with pure git
: Developers can't work in parallel on the same changeset. This is in stark contrast to pure git
, where all developers can freely create new commits, branch, and merge however they please, and git
is able to put all the pieces back together. But for this to work, commits must be constant in git
, a principle that is violated by the gerrit
workflow.
If you ask me, the best thing to do is to avoid using gerrit
. It's basic workflow is broken, and you are much better of using pure git
in the way that it is used by the linux developers.