1. Living with Gerrit Bruce Beare Android Architecture Intel Title

2. Talk Description This talk will present an overview of what Repo and Gerrit can do for you and look at a few of the less obvious but very cool things that you can do to form a more harmonious relationship with Gerrit. Agenda ● Overview of repo and gerrit ● Workflow for developers, reviewers, maintainers ● Branch maintenance ● Fun stuff for the cool kids

3. Overall Workflow http://groups.google.com/group/repo-discuss/web/repo-gerrit-git- workflow Code Developer Code Reviewer Code Maintainer repo git repository files commit & upload repo / gerrit Server +1 verified -1 failed +1 reviewed -1 failed Review comments … +1 verified -1 failed +1 reviewed -1 failed Review comments … MERGE

4. Getting Started

5. Getting Started...

7. Your initial workspace

8. Uploading a commit

9. Revising a commit

10. Revising a commit...

13. Frequently used Developer Commands repo init repo sync repo start git status git diff git commit git format-patch repo status repo upload repo prune git commit --amend git rebase -i HEAD^^..HEAD git log

14. Code Reviewer Use Case Code Reviewer As a code reviewer, I want to quickly check the submission to verify that it conforms to (below) so that I can ensure a higher product quality. ✔ Solves exactly one problem (can bisect) ✔ Architecturally sound ✔ Coding guidelines ✔ Understandable and Maintainable ✔ Doesn’t introduce new bugs ✔ Good commit message ✔ IP ownership

15. Gerrit home page

16. Add additional reviewers

17. Patch set 2

18. File by file review

19. Review approval

20. A more complex commit

21. Code Maintainer Use Case As a code maintainer, I want to quickly check the submission to verify that it conforms to (below) so that I can include the feature in my repository. ✔ Code reviewers have signed off ✔ Code testers have signed off ✔ Builds ✔ Passes required tests ✔ Merges cleanly Code Maintainer

22. What is ready to be merged?

23. View “starred” items

24. Cherry picking a change

25. Cherry picking a change...

26. Super-reviewer and verified

27. Branch Maintenance Adding a new branch (existing projects) –Requires git or gitosis permission –Create the branch and push Creating a new “git project” –Requires administrative ssh onto the gerrit server –Don't forget to push a “starter” file Adding the new project to your manifest file –The manifest file is in git... just like everything else –Commit and upload the change

28. Adding a new branch #!/bin/bash OLD_BRANCH=master NEW_BRANCH=my/new/branch/name PROJECTS=(\ [0]=a/aosp/platform/external/hostapd \ ) for p in ${PROJECTS[@]}; do echo " " echo "project --- $p ---" DIR=`basename $p` rm -rf $DIR git clone ssh://gerrit@android.intel.com:22/$p cd $DIR git checkout --track -b ${OLD_BRANCH} origin/${OLD_BRANCH} git checkout -b ${NEW_BRANCH} git push origin ${NEW_BRANCH} cd.. done

29. Creating a new “git project” #!/bin/bash WHOLE_PROJECT=$1 PROJECT=`basename $1` NEW_FILE=newproject.txt BRANCHES=(\ [0]=gingerbread-stable \ [1]=froyo-prod-bb \ ) ssh $USER@android.intel.com gerrit create-project --name ${WHOLE_PROJECT} git clone ssh://gerrit@android.intel.com:22/${WHOLE_PROJECT} cd ${PROJECT} touch ${NEW_FILE} git add ${NEW_FILE} git commit -s -m "initial project creation" git push origin master for new_branch in ${BRANCHES[@]}; do git checkout -b ${new_branch} git push origin ${new_branch} done

30. Adding your new project to a manifest file

31. Adding your new project to a manifest file...

32. Tricks for the cool kids A little more about manifest files Adding git remotes “repo forall” command Searching with the gerrit interface Using the gerrit command line interface Scripting with “starred” items

33. A little more about manifest files

34. Adding git remotes

35. "repo forall" command repo forall -c git clean -d -f -x repo forall -c git checkout korg/master repo forall build sdk -c 'git am patches/*' repo forall -c 'echo $REPO_PATH'

36. Searching with the gerrit interface

37. Using the gerrit command line interface gerrit ls-projects List projects visible to the caller. gerrit query Query the change database. gerrit review Verify, approve and/or submit a patch set from the https://review.source.android.com/Documentation/cmd-index.html

38. Scripting with "starred" items

39. starred_approve

40. starred_cherrypick

41. Further information http://git-scm.com/about http://code.google.com/p/git-repo http://code.google.com/gerrit https://review.source.android.com/ http://groups.google.com/group/repo-discuss/web/repo-gerrit-git- workflow http://umgwiki.intel.com/wiki/?title=Android_Starting_Points http://bjbeare-svr.jf.intel.com/ mailto:bruce.j.beare@intel.combruce.j.beare@intel.com

42. Backup...

43. More than Source Code Management git - Source code management (http://git-scm.com/about)http://git-scm.com/about Distributed development. Strong support for non-linear development. Efficient handling of large projects. Cryptographic authentication of history. Toolkit design. repo – Manages the many Git repositories (http://code.google.com/p/git-repo/)http://code.google.com/p/git-repo/ Manage many Git repositories. Uploads changes to the revision control system. Automates parts of the development work-flow gerrit – Web based code review system (http://code.google.com/gerrit)http://code.google.com/gerrit Graphical User Interface. Designed as a front-end for git (doesn't require repo).

44. About Git (http://git-scm.com/about) Distributed development. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required. Strong support for non-linear development. Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history. Efficient handling of large projects. Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long- term revision storage that currently tops any other open source version control system. Cryptographic authentication of history. The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed. Toolkit design. Following the Unix tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both easy human usage and easy scripting to perform new clever operations.

45. About Repo (http://code.google.com/p/git-repo/)http://code.google.com/p/git-repo/ Repo is a tool that is built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our revision control system, and automates parts of our development workflow. Repo is not meant to replace Git, only to make it easier to work with Git in the context of a larger development project. The repo command is an executable Python script that you can put anywhere in your path.

46. About Gerrit (http://code.google.com/p/gerrit)http://code.google.com/p/gerrit Gerrit is a web based code review system, facilitating online code reviews for projects using the Git version control system. Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer. Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer. This functionality enables a more centralized usage of Git.