Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to amend review issues in Gerrit when there is a second newer review also

Tags:

git

gerrit

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://[email protected]:29418/CommunicationsLibrary'

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

like image 330
Adrian Cornish Avatar asked Sep 19 '12 02:09

Adrian Cornish


People also ask

How do you rebase a Gerrit 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.

What is follow up change in Gerrit?

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.


2 Answers

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.

like image 144
Trevor Powell Avatar answered Oct 02 '22 07:10

Trevor Powell


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.

like image 22
xshoppyx Avatar answered Oct 01 '22 07:10

xshoppyx