Page History

...

1. Find the change number for the patch. This number can be found in the URL of the patch in the Gerrit web interface. 
   For example, if the URL of the link to the change-set is https://gerrit.onosproject.org/#/c/169/, the change number is 169.
    
   

2. Checkout the change. This creates a new branch for the changeset that represents this patch, with the naming convention review/submitter_name/branch_name.

   Code Block
   language text
   $ git review -d [commit_number]

   This needs to be done once for the changeset. If more amendments are needed for the patch later, one can simply check the branch out like any other:

   Code Block
   language text
   $ git checkout review/[submitter_name]/[branch_name]

3. Make changes and commit. Here, we use git commit --amend, instead of generating a new message.

   Code Block
   language text
   $ git add [modified file] $ git commit --amend

   Tip
   title Becareful Be Careful with Change-Id:
   Gerrit uses the Change-Id: ... in the commit comment to identify which changeset this commit belongs to. Make sure that you're not modifying the Change-Id: string when you're amending changes to the commit.  If you're squashing multiple commits together into a existing changeset, be sure to leave only the Change-Id: you want to use in the commit comment.

4. Resubmit. This creates a new patchset .It is very important to use the -R flag to avoid rebasing againon the existing review.

   Code Block
   language text
   $ git review -R

   Tip

   If Gerrit returns an error about a missing Change-Id, make sure that there is a Change-Id: string at the bottom of the commit message (above the comment blocks): Code Block language text Refactored PeerConnectivityManager for code reuse between the two path types.   Change-Id: Ib05f676d071ef1c545e93244a9ed5ed89672113e   # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit.

...