jami-docs

Forked version of Jami documentation, see wrycode.com/jami-docs-demo
git clone git://git.wrycode.com/wrycode/jami-docs.git
Log | Files | Refs

working-with-gerrit.md (3293B)


      1 # Working With Gerrit
      2 
      3 ## Account Setup
      4 
      5 + Gerrit server: https://review.jami.net
      6 + User documentation: https://review.jami.net/Documentation/intro-user.html
      7 + Jami projects on Gerrit: https://review.jami.net/#/admin/projects/
      8 
      9 1. Sign-in with your google or github account or git.jami.net account
     10 2. You'll also need to [upload an SSH key](https://review.jami.net/settings/#SSHKeys) to be able to commit changes for review.
     11 3. Don't forget to select a username.
     12 4. Finally, the email address specified in your git config must match one the email address registered with your Gerrit account.
     13 
     14 *Note for Savoir-faire Linux employees: please continue to use your @savoirfairelinux.com email address.*
     15 
     16 ## To Know your Git Config
     17 
     18 `git config --list`
     19 
     20 ## To Test your SSH Access
     21 
     22 To check that your SSH access is properly setup, run the following command:
     23 
     24 `ssh -p 29420 <username>@review.jami.net`
     25 
     26 <username> is your Gerrit username, that you should have set during the account creation. If not, you can do that here.
     27 
     28 ```
     29 If your access is granted, you should see a message like:
     30 
     31 ****    Welcome to Gerrit Code Review    ****
     32 
     33 Hi, you have successfully connected over SSH.
     34 
     35   Unfortunately, interactive shells are disabled.
     36   To clone a hosted Git repository, use:
     37 
     38   git clone ssh://<username>@review.jami.net:29420/REPOSITORY_NAME.git
     39 
     40 Connection to review.jami.net closed.
     41 ```
     42 
     43 ## Git Configuration
     44 
     45 Gerrit is the official git repository.
     46 
     47 ## To update the configuration
     48 
     49 You must update your remote information to use now the Gerrit repository. To do that, update your origin url:
     50 
     51 `git remote set-url origin ssh://<username>@review.jami.net:29420/<project_name>`
     52 
     53 Replace `<project_name>` by the correct project (example: ring-daemon)
     54 
     55 Or clone the existing repository if you want to start fresh.
     56 
     57 ## To Push by Default in refs/for/master
     58 
     59 You can configure git to automatically create a review when a change is pushed.
     60 
     61 `git config remote.origin.push HEAD:refs/for/master`
     62 
     63 ## To Create the Review
     64 
     65 When pushing to this magic branch, a review will automatically be created on Gerrit.
     66 
     67 `git push origin HEAD:refs/for/master`
     68 
     69 If you configured the default to refs/for/master as described above, simply
     70 
     71 `git push`
     72 
     73 If HEAD currently points to the branch with the commits you'd like to push. Ideally, you should work in a feature/bug branch for the issue at hand. Then you can do:
     74 
     75 `git push origin <bugfix_branchname>:refs/for/master`
     76 
     77 If this is the first time you've pushed, you will be prompted to install a post-commit Hook to insert a Change-ID in your commit message. Gerrit needs this to track patchsets and will reject pushes until you install it. Simply copy paste the command to install the hook as instructed by Gerrit, and amend your commits.
     78 
     79 ## To Push a Private patch
     80 
     81 You can push a work in progress (a.k.a draft) by pushing to refs/for/master%private
     82 
     83 For instance, you may want a "private" remote to push to; open <project_dir>/.git/config and add:
     84 
     85 ```
     86 [remote "private"]
     87 
     88 	url = ssh://<username>@review.jami.net:29420/ring-daemon
     89 	push = HEAD:refs/for/master%private
     90 ```
     91 
     92 Then:
     93 
     94 `git push private`
     95 
     96 Private work the same way as patchsets, except they are not visible to others by default and don't trigger any Jenkins builds. A draft can then be shared or published.