Still trying to learn how to use Gerrit and its process. Steps I did where
change1
to gerrit for review to HEAD:refs/for/develop
When you have dependent reviews in Gerrit (that is, one change in review which is dependent on an earlier change which is simultaneously in review), and you need to make modifications to the earlier change, you effectively have to resubmit both changes (since the second change becomes dependent on a different "parent" commit)
So the situation is that you have two commits in a single branch off of the main development branch, like this:
o master
\
o Commit A (in review, requires change)
o Commit B (in review, no changes required)
What I generally do in this situation is to make the changes requested of Commit A in a third commit. Our commit graph now looks like this:
o master
\
o Commit A (in review, requires change)
o Commit B (in review, no changes required)
o Commit C (modifications to Commit A)
Now I do git rebase -i master
and reorder Commit C to come after Commit A but before Commit B, and then squash it into Commit A. The commit graph now looks like this:
o master
\
o Commit A' (Commit A, incorporating the changes from Commit C)
o Commit B' (the same changes made in Commit B, but applied to Commit A' instead of A)
Finally, git review
(or whatever command you use to submit changes to gerrit) to re-submit both commits to Gerrit.
It's because of complications like this that most people strongly recommend working on each distinct change in a separate branch and then squashing down into a single commit before submitting to Gerrit, rather than needing to deal with these types of situations where you have dependent changes being reviewed at the same time.