6

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 command-line Git commands (no git-review, IDE, etc).

Pulling down the latest patch-set from the Gerrit server for a particular change is easy enough, but from there I'm not sure.

I would think the process would be:

  • fetch latest patch-set for change from server
  • rebase against latest patch-set
  • push

But during the rebase it marks all incoming changes as conflict, even if they weren't altered locally.

Perhaps this is related to the fact that the latest patch-set downloaded is not reachable by HEAD locally.

Can anyone suggest how multiple developers can work on the same change?

EDIT: The answer to this question are shown with the techniques described in: How to change a patchset and push it as a new one?

Community
  • 1
  • 1
Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
  • 1
    May I ask why? Usually, a change is owned by a single person who is responsible for it. If you need multiple developers that actually work on it, it sounds to me like the change is far too big and complicated to be a single change. – poke Nov 19 '15 at 20:16
  • 1
    I know that different places work differently, but at some of the places I've worked on we have a software developer and a styling/theme designer work on the same problem, each contributing their own particular expertise. It isn't really appropriate to make those separate changesets because the work constitutes a single change, and neither person's work stands alone. – Ralph Marshall Nov 19 '15 at 20:18
  • @poke, Remote pair-programming where developers are fixing a bug together is a use-case where a well-defined, small change could have multiple developers pushing patch-sets to the same change-set – Jonathan.Brink Nov 19 '15 at 20:26
  • Possible duplicate of [How to change a patchset and push it as a new one?](http://stackoverflow.com/questions/24457418/how-to-change-a-patchset-and-push-it-as-a-new-one) – Jonathan.Brink Feb 11 '16 at 22:12

1 Answers1

2

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.

cmaster - reinstate monica
  • 38,891
  • 9
  • 62
  • 106