This page documents:
- Asterisk's various Git repositories, and their intended purposes.
- Policies for using Git and Gerrit with Asterisk.
- Useful commands.
Asterisk uses Gerrit as its primary repository and for for code review. Users who are looking to clone or contribute patches back to Asterisk should work the repositories on Gerrit. Please see the Gerrit Usage documentation for more information.
The repositories on https://git.asterisk.org mirror the repositories on Gerrit, and provide source tree browsing.
The repositories on GitHub mirror the repositories on Gerrit, also provide source tree browsing, and exist because of GitHub's popularity.
Pull requests on GitHub WILL be ignored.
Anyone may clone repositories from Gerrit anonymously.
Users may participate in code reviews or contribute patches if they have signed a Contributor License Agreement. Access to Gerrit is performed using your JIRA (Atlassian) username/password. You may create an account at https://signup.asterisk.org, and sign a CLA in JIRA. Note that you will not be able to log into Gerrit if a CLA is not associated with your JIRA account.
-2should only be used if the current implementation requires a complete rewrite to be acceptable, or if the change should not be made under any implementation.
+2should generally not be given unless someone has already given the review a
- Related to the previous, users who provide a
+2should generally not provide it to a change that they provided the
- Please read the Asterisk project Coding Guidelines prior to submitting patches. When performing code reviews, please refer to the Code Review Checklist.
Please use the
git review, specifying the ASTERISK issue the change should be associated with:
This helps to tie Gerrit reviews to the JIRA issue that necessitated the change.
- All branches that require the change should have the change cherry-picked to that branch, and submitted for review. See Software Configuration Management Policies for which patch types are appropriate for what branches. See Gerrit Usage for instructions on cherry-picking.
- The same Gerrit
Change Idmust be present in all cherry-picked commits.
- The same topic (ASTERISK issue) must be used in all reviews.
- Test Suite test reviews should use the same topic (ASTERISK issue) as the code change reviews.
Useful Commands and Tips
git clean: When switching between major release branches there are often whole directories that are in one branch but not another. '
git clean -fd' will clean out the working directory. Just make sure any files you want to keep are either checked in or ignored.
- If you use an IDE or other tools that need configuration files in the working directory but their names don't match an entry in .gitignore, you can add them to git/info/exclude to ignore them locally without updating the checked-in .gitignore.
git log: This is one of the more useful tools there is. Here are some examples:Show the commit difference between 13.8 and 13.9
Show the difference between the 13.8 and 13.9 branches:
Both are branches so you'll see the diff between their current states with the merge and housekeeping commits excluded.
That's a lot to type so add an alias:
Show the commits added to 13.9 after up to 13.9.1
Wait, that didn't show anything! That's because 13.9.1 is a tag on 13.9 and nothing's been added to 13.9 since then so they're equal. What you probably want is:
Now things get a little complicated. Let's say 13.8 is closed but certified/13.8 is still open. So, what's in certified/13.8 but not 13.8? You might be tempted to use the
'..'operator between the 2 branches as before but because
'..'is a range operator it doesn't work well when the 2 branches overlap, especially when we're cherry-picking; you'll wind up showing commits that are in both branches. Instead, you need to use the
'...'operator and the
Finally, things get even more complicated when trying to compare 13 and master. Because of the cherry-picking and the fact that these 2 branches started in subversion, there is no single git command that will show the differences reliably. The only way to do this is to pick a point in time as a starting reference, list the log from both branches, sort them, then compare them. It would be nice if git could do the matching on the gerrit change id but it can't so we're left with mathcing on subject
April 11 2015 was the migration from subversion to git. Also note that the 2 app_amd commits are probably the same but we have no way to tell.