How to improve the commit that gerrit verified as -1?

Question

If a commit is marked verified = -1 in gerrit, how developer change that commit and resend the git review? As far As I know, the top commit could be changes by git commit --ammend, but how to improve the other commits before (not on the top).

Answer 1

My experience with gerrit stopped around version 2.7.0 (~1.5 years ago) but I guess the main principles remain unchanged. A commit suitable for Gerrit review is marked with a line Change-Id: Ixxxx , where xxxx is 20-digit hex value (SHA-1 output). This identifier is used to match updated versions of the same proposal, so, if you push a commit with the same id, it will be presented by gerrit as updated "patch set" of the same change, despite its git id has been changed.

If you have an unmerged sequence of commits, and you have to change the non-final one, use git interactive rebase ( git rebase --interactive ) to update commits inside this sequence. You can choose a method to update these commits - eg editing manually, or creating another commit with fix and using fixup command... this isn't principal. As a result of this change, you will have an updated sequence. For example, initial version of 3-commit series is:

git id = 1234, gerrit id = Iabcd;
git id = 5678, gerrit id = Ief01;
git id = 9abc, gerrit id = I2345.

After editing the first commit, you will have:

git id = 9876, gerrit id = Iabcd;
git id = 5432, gerrit id = Ief01;
git id = 10fe, gerrit id = I2345.

As one can see, git ids change, but gerrit ids don't. Then, push the whole sequence (through the final commit id or simply HEAD ), and gerrit site will show new patch sets for the same commits (matched them by combination of gerrit id and branch).

You can also add new commits (they will appear out of order at the basic dashboard view), abandon some (eg merged with others)... Also you can regenerate gerrit-id (the default commit hook does this if id line is deleted manually), dropping the connection with the old commit history.

If it has a verification hook active, the whole set of new patch sets will be rechecked; also it needs manual review. With the default review policy, all marks -1, 0, +1, +2 aren't passed automatically to a new patch set of the same commit, but -2 is passed so the respective reviewer has to change it even if he doesn't say a new opinion.

In my practice, I used to form long sequences of such commits, if needed for an appropriate work, like a deep refactoring, and, yes, there were cases when a commit at beginning of the sequence needed changing. The really stodgy feature of such situation is that any reviewer has to reapprove later commits, even if they aren't changed, and that gerrit diff between patch sets of the same commit exposes all changes happened earlier in the commit sequence. I hope this will be assisted in some future gerrit releases.