Cloning from Gerrit
While access to the underlying git repository is open to anyone via anonymous HTTP access, this guide will assume that you want to push changes up as well. For that, Gerrit uses SSH. If you are only looking to obtain the source code for a particular repository, you may just use the HTTP methods shown below.
- Clone the repository:
- You can clone a specific repo branch only:
Cloning Asterisk branch 13 via HTTP to the "asterisk-13" folder:
commit-msghook into your local
Creating an SSH Alias
Since access to gerrit.asterisk.org is likely to occur often, you may want to set up an SSH alias:
This will allow you to access the repository as shown below:
Pushing to Gerrit for Code Review
To submit a change to
masteras a draft:
To submit a change to
Note that this will automatically publish the change tothe
To submit a change for a particular branch:
To submit a change, including the
ASTERISKissue if there is one as the topic for the review:
Pushing to Gerrit for code review can always be done using standard
git commands. This is done by pushing to the
refs/for/[branch]. Generally, this will be
master, unless pushing to a particular mainline Asterisk branch.
Updating a Review
Reviews are automatically updated so long as commits contain the same Change ID. If your review has any findings, rebase the commits as appropriate, making sure the Change ID is preserved:
Re-push the changes:
Patches being submitted to the project must be cherry-picked to other branches when either:
- The patch is a bug fix. In this case, the patch should be cherry-picked to all supported branches that have the bug.
The patch is a new feature or improvement, and tests have been written to cover the new feature or improvement. In that case, the patch may be submitted to other supported branches.
Cherry-picking can be done either when a patch is first proposed, or it may be done when the patch has been reviewed but prior to it being submitted. If you plan on cherry-picking after an initial review, please indicate so in a comment on the review.
Cherry-Picking in Gerrit
If your patch applies cleanly to a branch, you can cherry-pick directly in Gerrit. On your review, select the Cherry-Pick button:
In the resulting dialog, enter the branch you want to cherry-pick to, then select Cherry Pick Change.
If the change merges cleanly, a new review will be opened with your cherry-picked change. If the change could not be merged, and error will appear and you will need to use one of the manual methods listed below.
If you have already submitted a patch for review, you may cherry pick to a new branch using
As an example, if we previously posted for review a code change for Asterisk 11, and the Gerrit Review ID is 30, we might use the following for Asterisk 13:
You may cherry pick using
git cherry-pick as well. When performing the cherry-pick using git, make sure that the
Change-Id header is the same between all branches.
As an example, if we committed the following to Asterisk 13:
We could then cherry pick this back to Asterisk 11 using the following:
The resulting commit must have the same Change-Id as the Asterisk 13 commit for Gerrit to recognize that this is a cherry-picked commit:
When posting it for review to Gerrit, you should also use the same topic as the original patch. Generally, this is the ASTERISK issue.
The repositories on Gerrit typically require all changes in all of the mainline branches to be reviewed prior to merging. While this is appropriate for the mainline branches, sometimes, it is useful to have a branch on the central server that multiple developers can use for collaboration. These branches exist within a special branch namespace,
team. Registered Gerrit users have the ability to manipulate branches within that namespace directly, bypassing the usual Gerrit code review process.
Team Branch Manipulation in Gerrit
Creating a new Team Branch
Creating a new team branch can be done at any time from a local branch. For example, to create a new team branch from local
Check out a Team Branch
Checking out a team branch is done in the same way as a mainline branch:
Pushing to a Team Branch
Pushing to a team branch can be done directly. This bypasses Gerrit's peer review. Note that team branches can be peer reviewed if desired, using the same mechanism as a 'normal' Gerrit peer review.
Delete a Team Branch
Deleting a team branch is done by pushing an empty local branch (nothing) to the team branch. Note that you have to use
git push --force.
Recovering a Subversion Team Branch
While the Subversion Team branches were moved over to Git with their entire history, much of that history typically consists of Automerge commits. These commits are not well understood by Git; from Git's perspective, they are completely independent from the mainline commits they merged over. This can cause a "standard" rebase to fail miserably: the rebase will not realize that the Automerge commits are identical to those on the branch being rebased to. As a result, you'll often have a lot of merge conflicts if you attempt to rebase directly.
While working through the merge conflicts in a rebase is an option, an easier approach may be to simply re-build the branch on the current state of the mainline branch it wants to track. This example walks through that process, performing a rebase of branch
team/mjordan/trunk-http-stuff-and-things on top of
Checkout the subversion team history branch into a temporary local branch:
- Determine the useful commits to pull over. In this case, we're going to skip:
- All commits from
- All commits that modify Subversion properties or create Subversion branches.
In the above screenshot, we want the three commits from
Matthew Jordanbetween the
automerge canceland the
Matthew Jordan: Re-enable automerge.
- Record the hashes of the commits you want to carry-over.
- All commits from
Checkout a new branch for your work, tracking whatever canonical mainstream branch is appropriate:
Cherry-pick each commit over, solving merge conflicts as necessary:
If desired, fix up any history:
Remove the temporary branch:
Push the branch up to your team branch location:
Problem: attempting to run
git review results in something like the following:
on your command line
Problem: attempting to run
git review results in "unpack failed: error Missing tree":
Description: There is an incompatibility between certain version of git and gerrit that causes this error when the commit to be pushed was amended and only the commit message changed.
Solution: Run git push manually with the --no-thin option:
Problem: Unable to login to gerrit.asterisk.org
Solution: Until your Contributor License Agreement is approved, you will not be able to sign into the project OpenID provider or Gerrit. See the "Creating an Account" section for instructions on how to resolve this.
Problem: Unable to unsubscribe from Gerrit notifications
Solution: You may have mistaken the Gerrit notifications on a mailing list for notifications associated with your account. Of course if the notifications are being received via a mailing list then you would need to unsubscribe from the entire mailing list to stop receiving related mailings.
Other possibilities are that you have multiple accounts or are receiving notifications via forwarding from another E-mail address.