1. Review a Change
In this exercise you will do a code review in Gerrit.
Preparation
● follow the exercise 2 to create an open change in Gerrit.
You can review your own change or a change created by somebody else.
In practice you will usually review changes created by other developers and others will review
your changes. Therefore, try to find a change (for egit-training) not created by you and use it for
this exercise.
A review of a simple change is usually done in the Gerrit UI. However, for a more complex
change you may want to fetch it into your local Git repository, build and test it and look at it in
Eclipse.
Review the source code changes from Gerrit
A change may consist of one or more patch sets. Each patch set corresponds to one Git
commit. Newer patchsets replace previous ones when the author reacts on review comments
by improving the previous patchset and creates a new commit using “commit amend” to replace
the previous commit. When a change has more than one patch set it is only necessary to review
the latest patch set since it’s the one replacing all previous ones within the same change ! This
is an important principle in Gerrit to remember.
Steps:
● Look at the list of files under the latest patch set (patch set 1 in this case). These are the
files that were added, modified or deleted within this change.
● click the Side-by-Side link of a file to open a page displaying the changes done in this
file. The left side shows the “old version” and the right side shows the “new version” of
the file. The diff is highlighted:
2. ● Think about every change you see
● If you want to comment on a line just double click it and type in your
comment:
● Click Save in order to save the (draft of) your comment
○ NOTE: the comments you create are not yet visible to anybody else but you.
Only when you publish your comments they will become visible to everybody.
● Continue reviewing other files in the same way
3. Review the commit message
Providing a good commit message is as important as writing good code. A good commit
message should describe why (the motivation) and not what. When months or years later you
look at a change in your Git history you will easily see what was changed. However, only if the
commit message was good we will know why this change was made.
Therefore, Gerrit also provides review of the commit message. It is done the same way as
reviewing a file and the commit message appear at the top of the file list:
Vote and Publish Comments
● Click the “Up to Change” link to go back to the change screen
● Click the “Review” button
● Vote in the “Code Review” category
4. ● Vote +1 in the “Verified” and the “IP Clean” categories. Normally, this is not done by the
code reviewer but we don’t have IP review for the egit-training project. If you are running
against http://git.eclipse.org/r/ the Verified vote will be done by a Hudson job which is
verifying all changes pushed for review.
● Write the cover message and click the “Publish Comments” button:
You are done with the review! Now the author of the change can read your comments and
provide an improved new patchset in the next review iteration.
The next chapter shows another possibility which is useful when reviewing more complex
changes:
Fetching the change into local repository
When a change is more complex you may want to fetch it into your local Git repository in order
to look at it from Eclipse. In that case you may build it locally, debug it etc...
To fetch a change first note the numerical change ID of it. Look at the URL of the change in the
web browser and locate the numerical Change ID:
In this case it is 4445.
In Eclipse right-click the Git repository node and select Fetch from Gerrit…:
5. In the “Fetch a change from Gerrit” dialog enter the Change ID:
