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

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

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

Ardithardme

Does the 2nd change you pushed to Gerrit have the 1st thing you pushed as a dependency? – Pesthouse

Yes it does have the 1st change as a dependency – Ardithardme

I haven't had time to try this today - thanks for you answers will try tomorrow - haven't forgotten about it :-) – Ardithardme

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.

Trichocyst

An update, a year later: Instead of the procedure I outlined above, I now just do a single git rebase -i master, and set the command for Commit A to be "edit" (leave the command for Commit B as "pick"). That will leave you in rebasing-mode, with commit A in your working copy. You can then amend commit A using git commit --amend. Once you finish modifying commit A, you can then git rebase --continue, and it will re-apply commit B, and you're done. – Trichocyst

What do you do before git rebase -i master? I ask this because I think one need to download (e.g. git review -d <number>) the newest dependent patchset, but not the one you want to edit right? Otherwise you will only get the Commit A and not Commit A and Commit B in the rebase. – Sadowski

@KyuuSung The question being answered specified that Commit A and Commit B both already exist on the local machine, and are in the same branch. No other commands should be needed in that situation. If you're not in that situation, you can fetch commit B from the gerrit server in the usual way (the review request page provides the necessary command to do this, for your server). After doing that and checking out commit B, you'll be in a state where you can follow these instructions. – Trichocyst

@KyuuSung Note that this answer is rather old, and I've not used Gerrit in several years. The above comment is based only on my current memory of how it worked years ago. – Trichocyst

Answer 2

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.

Pesthouse

Thanks for your answer - I accepted Trevor's because it was first – Ardithardme

No worries, I don't really care if my reply was accepted or not. I'm just glad it helped you :) – Pesthouse

Answer 3

The situation is exactly like @Trevor explained. rebase -i is a good way to do when you have this condition.

Personally, I use this command as well but with a little bit different:

1. Use --fixup and --autosquash

you have two commits:

old commit
new commit

when you want to change old commit, then

 git commit --fixup <old_commit_id>

then rebase with autosquash,

git rebase -i --autosquash <commit_id_before_old_commit>

If it's unclear of my comments, you can check the detail in: https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html

OR

2. Take advantage of Gerrit

After you commit two changes, you will have two open-reviews change on you GUI.

Then go to your "old change", select download -> checkout this change, actually after you checkout, you will go to a branch for this change, then fix your code, amend, rebase, push ... like what you do as usual.

Polyphemus

Answer 4

call

commit --ammend

instead for your 2nd change

Aliment

Answer 5

just git commit --amend then git review

Hawthorn

how do I find the commit to --amend to when in git review I have a list of several commits? – Teodor

Answer 6

I tried with these attempts

1. did git rebase -i master
   it didn't work
2. then last what I did, I took backup of files. Deleted the whole project. then cloned it again. Paste files in the required folder from backup and then recommitted again and then pushed. It worked .

Distributive