Question

Still trying to learn how to use Gerrit and its process. Steps I did where

1. Push first change1 to gerrit for review to HEAD:refs/for/develop
2. Work on something else on same branch and push change2 to gerrit for review to HEAD:refs/for/develop

Both commits have gerrit Change-ID lines

So now I want to address issue for change1 so I did

git checkout -b change1 <change 1's commit id>

Made my changes and committed (adding the Change-ID to the commit message)

git add .
git commit

Now when I do

git push origin HEAD:refs/for/develop

I get

 ! [remote rejected] HEAD -> refs/for/develop (squash commits first)
error: failed to push some refs to 'ssh://adrian@192.168.7.100:29418/CommunicationsLibrary'

How do I fix issues in stacked reviews and post it to gerrit without having to create yet another review?

Answer 1

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.