Still trying to learn how to use Gerrit and its process. Steps I did where
change1
to gerrit for review to HEAD:refs/for/developchange2
to gerrit for review to HEAD:refs/for/developBoth 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://[email protected]:29418/CommunicationsLibrary'
How do I fix issues in stacked reviews and post it to gerrit without having to create yet another review?
Just click on "Rebase" button to rebase the change. The behaviour is described in Gerrit Review UI: If the rebase is successful, a new patch set with the rebased commit is created. If the rebase fails, there are conflicts that have to be resolved manually.
The Follow-Up changes are changes that are based on existing changes. This gives you an opportunity to create a chain of related changes. The "follow-up" feature allows you to create change-sets very quickly.
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.
I think your problem is related to the fact that the amendment to the 1st commit has the second commit as a dependency now. This is what I would personally do but there may be a better way. I look at it as you want to rebase the way your commits are and you are dealing with the last 3. So run 'git rebase -i HEAD~3'. This allows you to rebase the last 3 commits via switching the order or melding them to each other. You should be aware that it lists the commits in oldest-first order. Here's an example:
git log is as follows:
commit info:......
message: foo2
commit info:......
message: bar1
commit info:......
message: foo1
After running the above command an editor should pop up with the following:
pick foo1.
pick bar1.
pick foo2.
(This is assuming your second foo change didn't change any of the files that bar1 changed as this might not work and if you did do that you should have amended the commit anyway.) Then change the list to this:
pick foo1
fixup foo2
pick bar1
After that you will have foo1 and foo2 squashed into one commit and bar1 will be the commit following. Then I would run 'git reset --soft HEAD~1' resetting the newest commit, followed by a 'git commit --amend' which allows you to change the commit message for the first review and make sure to include the change-id. Then try your push. After that you should have a new patch set up, and all the files the second change was will be modified and still in your working directory.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With