doc/contribute.html - go - Git at Google

 <!--{
 	"Title": "Contribution Guidelines"
 }-->

 <h2 id="Introduction">Introduction</h2>

 <p>
 This document explains how to contribute changes to the Go project.
 It assumes you have followed the
 <a href="/doc/install/source">installation instructions</a> and
 have <a href="code.html">written and tested your code</a>.
 </p>

 <p>
 (Note that the <code>gccgo</code> frontend lives elsewhere;
 see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
 </p>

 <h2 id="Design">Discuss your design</h2>

 <p>
 The project welcomes submissions but please let everyone know what
 you're working on if you want it to become part of the main repository.
 </p>

 <p>
 Before undertaking to write something new for the Go project, send
 mail to the <a href="https://groups.google.com/group/golang-nuts">mailing
 list</a> to discuss what you plan to do.  This gives everyone a
 chance to validate the design, helps prevent duplication of effort,
 and ensures that the idea fits inside the goals for the language
 and tools.  It also guarantees that the design is sound before code
 is written; the code review tool is not the place for high-level
 discussions.
 </p>

 <p>
 In short, send mail before you code.
 And don't start the discussion by mailing a change list!
 </p>

 <h2 id="Testing">Testing redux</h2>

 <p>
 You've <a href="code.html">written and tested your code</a>, but
 before sending code out for review, run all the tests for the whole
 tree to make sure the changes don't break other packages or programs:
 </p>

 <pre>
 $ cd go/src
 $ ./all.bash
 </pre>

 <p>
 (To build under Windows use <code>all.bat</code>.)
 </p>

 <p>
 After running for a while, the command should print
 "<code>ALL</code> <code>TESTS</code> <code>PASSED</code>".
 </p>

 <h2 id="Code_review">Code review</h2>

 <p>
 Changes to Go must be reviewed before they are accepted,
 no matter who makes the change.
 A custom git command called <code>git-codereview</code>,
 discussed below, helps manage the code review process through a Google-hosted
 <a href="https://go-review.googlesource.com/">instance</a> of the code review
 system called <a href="https://code.google.com/p/gerrit/">Gerrit</a>.
 </p>

 <h3>Set up authentication for code review</h3>

 <p>
 Gerrit uses Google Accounts for authentication. If you don't have
 a Google Account, you can create an account which
 <a href="https://www.google.com/accounts/NewAccount">includes
 a new Gmail email account</a> or create an account associated
 <a href="https://accounts.google.com/SignUpWithoutGmail">with your existing
 email address</a>.
 </p>

 <p>
 The email address associated with the Google Account you use will be recorded in
 the <a href="https://go.googlesource.com/go/+log/">change log</a>
 and in the <a href="/CONTRIBUTORS">contributors file</a>.
 </p>

 <p>
 To set up your account in Gerrit, visit
 <a href="https://go.googlesource.com">go.googlesource.com</a>
 and click on "Generate Password" in the page's top right menu bar.
 </p>

 <p>
 You will be redirected to accounts.google.com to sign in.
 </p>

 <p>
 Once signed in, you are returned back to go.googlesource.com to "Configure Git".
 Follow the instructions on the page.
 (If you are on a Windows computer, you should instead follow the instructions
 in the yellow box to run the command.)
 </p>

 <p>
 Your secret authentication token is now in a <code>.gitcookie</code> file
 and Git is configured to use this file.
 </p>

 <h3>Register with Gerrit</h3>

 <p>
 Now that you have your authentication token,
 you need to register your account with Gerrit.
 To do this, visit
 <a href="https://go-review.googlesource.com/login/">
 go-review.googlesource.com/login/</a>. You will immediately be redirected
 to Google Accounts. Sign in using the same Google Account you used above.
 That is all that is required.
 </p>

 <h3>Install the git-codereview command</h3>

 <p>
 Now install the <code>git-codereview</code> command by running,
 </p>

 <pre>
 $ go get -u golang.org/x/review/git-codereview
 </pre>

 <p>
 Make sure <code>git-codereview</code> is installed in your shell path, so that the
 <code>git</code> command can find it. Check that
 </p>

 <pre>
 $ git codereview help
 </pre>

 <p>
 prints help text, not an error.
 </p>

 <p>
 Note to Git aficionados: The <code>git-codereview</code> command is not required to
 upload and manage Gerrit code reviews. For those who prefer plain Git, the text
 below gives the Git equivalent of each git-codereview command. If you do use plain
 Git, note that you still need the commit hooks that the git-codereview command
 configures; those hooks add a Gerrit <code>Change-Id</code> line to the commit
 message and check that all Go source files have been formatted with gofmt. Even
 if you intend to use plain Git for daily work, install the hooks in a new Git
 checkout by running <code>git-codereview</code> <code>hooks</code>.
 </p>

 <h3>Set up git aliases</h3>

 <p>
 The <code>git-codereview</code> command can be run directly from the shell
 by typing, for instance,
 </p>

 <pre>
 $ git codereview sync
 </pre>

 <p>
 but it is more convenient to set up aliases for <code>git-codereview</code>'s own
 subcommands, so that the above becomes,
 </p>

 <pre>
 $ git sync
 </pre>

 <p>
 The <code>git-codereview</code> subcommands have been chosen to be distinct from
 Git's own, so it's safe to do so.
 </p>

 <p>
 The aliases are optional, but in the rest of this document we will assume
 they are installed.
 To install them, copy this text into your Git configuration file
 (usually <code>.gitconfig</code> in your home directory):
 </p>

 <pre>
 [alias]
 	change = codereview change
 	gofmt = codereview gofmt
 	mail = codereview mail
 	pending = codereview pending
 	submit = codereview submit
 	sync = codereview sync
 </pre>

 <h3>Understanding the git-codereview command</h3>

 <p>After installing the <code>git-codereview</code> command, you can run</p>

 <pre>
 $ git codereview help
 </pre>

 <p>
 to learn more about its commands.
 You can also read the <a href="https://godoc.org/golang.org/x/review/git-codereview">command documentation</a>.
 </p>

 <h3>Switch to the master branch</h3>

 <p>
 Most Go installations use a release branch, but new changes should
 only be made based on the master branch.
 (They may be applied later to a release branch as part of the release process,
 but most contributors won't do this themselves.)
 Before making a change, make sure you start on the master branch:
 </p>

 <pre>
 $ git checkout master
 $ git sync
 </pre>

 <p>
 (In Git terms, <code>git</code> <code>sync</code> runs
 <code>git</code> <code>pull</code> <code>-r</code>.)
 </p>

 <h3>Make a change</h3>

 <p>
 The entire checked-out tree is writable.
 Once you have edited files, you must tell Git that they have been modified.
 You must also tell Git about any files that are added, removed, or renamed files.
 These operations are done with the usual Git commands,
 <code>git</code> <code>add</code>,
 <code>git</code> <code>rm</code>,
 and
 <code>git</code> <code>mv</code>.
 </p>

 <p>
 If you wish to checkpoint your work, or are ready to send the code out for review, run</p>

 <pre>
 $ git change <i>&lt;branch&gt;</i>
 </pre>

 <p>
 from any directory in your Go repository to commit the changes so far.
 The name <i>&lt;branch&gt;</i> is an arbitrary one you choose to identify the
 local branch containing your changes.
 </p>

 <p>
 (In Git terms, <code>git</code> <code>change</code> <code>&lt;branch&gt;</code>
 runs <code>git</code> <code>checkout</code> <code>-b</code> <code>branch</code>,
 then <code>git</code> <code>branch</code> <code>--set-upstream-to</code> <code>origin/master</code>,
 then <code>git</code> <code>commit</code>.)
 </p>

 <p>
 Git will open a change description file in your editor.
 (It uses the editor named by the <code>$EDITOR</code> environment variable,
 <code>vi</code> by default.)
 The file will look like:
 </p>

 <pre>

 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch foo
 # Changes not staged for commit:
 #	modified:   editedfile.go
 #
 </pre>

 <p>
 At the beginning of this file is a blank line; replace it
 with a thorough description of your change.
 The first line of the change description is conventionally a one-line
 summary of the change, prefixed by the primary affected package,
 and is used as the subject for code review mail.
 The rest of the
 description elaborates and should provide context for the
 change and explain what it does.
 If there is a helpful reference, mention it here.
 </p>

 <p>
 After editing, the template might now read:
 </p>

 <pre>
 math: improved Sin, Cos and Tan precision for very large arguments

 The existing implementation has poor numerical properties for
 large arguments, so use the McGillicutty algorithm to improve
 accuracy above 1e10.

 The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm

 Fixes #159

 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch foo
 # Changes not staged for commit:
 #	modified:   editedfile.go
 #
 </pre>

 <p>
 The commented section of the file lists all the modified files in your client.
 It is best to keep unrelated changes in different change lists,
 so if you see a file listed that should not be included, abort
 the command and move that file to a different branch.
 </p>

 <p>
 The special notation "Fixes #159" associates the change with issue 159 in the
 <a href="https://golang.org/issue/159">Go issue tracker</a>.
 When this change is eventually submitted, the issue
 tracker will automatically mark the issue as fixed.
 (There are several such conventions, described in detail in the
 <a href="https://help.github.com/articles/closing-issues-via-commit-messages/">GitHub Issue Tracker documentation</a>.)
 </p>

 <p>
 Once you have finished writing the commit message,
 save the file and exit the editor.
 </p>

 <p>
 If you wish to do more editing, re-stage your changes using
 <code>git</code> <code>add</code>, and then run
 </p>

 <pre>
 $ git change
 </pre>

 <p>
 to update the change description and incorporate the staged changes.  The
 change description contains a <code>Change-Id</code> line near the bottom,
 added by a Git commit hook during the initial
 <code>git</code> <code>change</code>.
 That line is used by Gerrit to match successive uploads of the same change.
 Do not edit or delete it.
 </p>

 <p>
 (In Git terms, <code>git</code> <code>change</code> with no branch name
 runs <code>git</code> <code>commit</code> <code>--amend</code>.)
 </p>

 <h3>Mail the change for review</h3>

 <p>
 Once the change is ready, mail it out for review:
 </p>

 <pre>
 $ git mail
 </pre>

 <p>
 You can specify a reviewer or CC interested parties
 using the <code>-r</code> or <code>-cc</code> options.
 Both accept a comma-separated list of email addresses:
 </p>

 <pre>
 $ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
 </pre>

 <p>
 Unless explicitly told otherwise, such as in the discussion leading
 up to sending in the change list, it's better not to specify a reviewer.
 All changes are automatically CC'ed to the
 <a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
 mailing list.
 </p>

 <p>
 (In Git terms, <code>git</code> <code>mail</code> pushes the local committed
 changes to Gerrit using <code>git</code> <code>push</code> <code>origin</code>
 <code>HEAD:refs/for/master</code>.)
 </p>

 <p>
 If your change relates to an open issue, please add a comment to the issue
 announcing your proposed fix, including a link to your CL.
 </p>

 <p>
 The code review server assigns your change an issue number and URL,
 which <code>git</code> <code>mail</code> will print, something like:
 </p>

 <pre>
 remote: New Changes:
 remote:   https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
 </pre>

 <h3>Reviewing code</h3>

 <p>
 Running <code>git</code> <code>mail</code> will send an email to you and the
 reviewers asking them to visit the issue's URL and make comments on the change.
 When done, the reviewer adds comments through the Gerrit user interface
 and clicks "Reply" to send comments back.
 You will receive a mail notification when this happens.
 You must reply through the web interface.
 (Unlike with the old Rietveld review system, replying by mail has no effect.)
 </p>

 <h3>Revise and upload</h3>

 <p>
 You must respond to review comments through the web interface.
 (Unlike with the old Rietveld review system, responding by mail has no effect.)
 </p>

 <p>
 When you have revised the code and are ready for another round of review,
 stage those changes and use <code>git</code> <code>change</code> to update the
 commit.
 To send the update change list for another round of review,
 run <code>git</code> <code>mail</code> again.
 </p>

 <p>
 The reviewer can comment on the new copy, and the process repeats.
 The reviewer approves the change by giving it a positive score
 (+1 or +2) and replying <code>LGTM</code>: looks good to me.
 </p>

 <p>
 You can see a list of your pending changes by running <code>git</code>
 <code>pending</code>, and switch between change branches with <code>git</code>
 <code>change</code> <code><i>&lt;branch&gt;</i></code>.
 </p>

 <h3>Synchronize your client</h3>

 <p>
 While you were working, others might have submitted changes to the repository.
 To update your local branch, run
 </p>

 <pre>
 $ git sync
 </pre>

 <p>
 (In git terms, <code>git</code> <code>sync</code> runs
 <code>git</code> <code>pull</code> <code>-r</code>.)
 </p>

 <p>
 If files you were editing have changed, Git does its best to merge the
 remote changes into your local changes.
 It may leave some files to merge by hand.
 </p>

 <p>
 For example, suppose you have edited <code>sin.go</code> but
 someone else has committed an independent change.
 When you run <code>git</code> <code>sync</code>,
 you will get the (scary-looking) output:

 <pre>
 $ git sync
 Failed to merge in the changes.
 Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
 The copy of the patch that failed is found in:
    /home/you/repo/.git/rebase-apply/patch

 When you have resolved this problem, run "git rebase --continue".
 If you prefer to skip this patch, run "git rebase --skip" instead.
 To check out the original branch and stop rebasing, run "git rebase --abort".
 </pre>

 <p>
 If this happens, run
 </p>

 <pre>
 $ git status
 </pre>

 <p>
 to see which files failed to merge.
 The output will look something like this:
 </p>

 <pre>
 rebase in progress; onto a24c3eb
 You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
   (fix conflicts and then run "git rebase --continue")
   (use "git rebase --skip" to skip this patch)
   (use "git rebase --abort" to check out the original branch)

 Unmerged paths:
   (use "git reset HEAD &lt;file&gt;..." to unstage)
   (use "git add &lt;file&gt;..." to mark resolution)

 	<i>both modified: sin.go</i>
 </pre>

 <p>
 The only important part in that transcript is the italicized "both modified"
 line: Git failed to merge your changes with the conflicting change.
 When this happens, Git leaves both sets of edits in the file,
 with conflicts marked by <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
 <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code>.
 It is now your job to edit the file to combine them.
 Continuing the example, searching for those strings in <code>sin.go</code>
 might turn up:
 </p>

 <pre>
 	arg = scale(arg)
 &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
 	if arg &lt; 1e9 {
 =======
 	if arg &lh; 1e10 {
 &gt;&gt;&gt;&gt;&gt;&gt;&gt; mcgillicutty
 		largeReduce(arg)
 </pre>

 <p>
 Git doesn't show it, but suppose the original text that both edits
 started with was 1e8; you changed it to 1e10 and the other change to 1e9,
 so the correct answer might now be 1e10.  First, edit the section
 to remove the markers and leave the correct code:
 </p>

 <pre>
 	arg = scale(arg)
 	if arg &lt; 1e10 {
 		largeReduce(arg)
 </pre>

 <p>
 Then tell Git that the conflict is resolved by running
 </p>

 <pre>
 $ git add sin.go
 </pre>

 <p>
 If you had been editing the file, say for debugging, but do not
 care to preserve your changes, you can run
 <code>git</code> <code>reset</code> <code>HEAD</code> <code>sin.go</code>
 to abandon your changes.
 Then run <code>git</code> <code>rebase</code> <code>--continue</code> to
 restore the change commit.
 </p>

 <h3>Reviewing code by others</h3>

 <p>
 You can import a change proposed by someone else into your local Git repository.
 On the Gerrit review page, click the "Download ▼" link in the upper right
 corner, copy the "Checkout" command and run it from your local Git repo.
 It should look something like this:
 </p>

 <pre>
 $ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 &amp;&amp; git checkout FETCH_HEAD
 </pre>

 <p>
 To revert, change back to the branch you were working in.
 </p>

 <h3>Submit the change after the review</h3>

 <p>
 After the code has been <code>LGTM</code>'ed, an approver may
 submit it to the master branch using the Gerrit UI.
 There is a "Submit" button on the web page for the change
 that appears once the change is approved (marked +2).
 </p>

 <p>
 This checks the change into the repository.
 The change description will include a link to the code review,
 and the code review will be updated with a link to the change
 in the repository.
 Since the method used to integrate the changes is "Cherry Pick",
 the commit hashes in the repository will be changed by
 the submit operation.
 </p>

 <h3>More information</h3>

 <p>
 In addition to the information here, the Go community maintains a <a href="https://golang.org/wiki/CodeReview">CodeReview</a> wiki page.
 Feel free to contribute to this page as you learn the review process.
 </p>

 <h2 id="copyright">Copyright</h2>

 <p>Files in the Go repository don't list author names,
 both to avoid clutter and to avoid having to keep the lists up to date.
 Instead, your name will appear in the
 <a href="https://golang.org/change">change log</a>
 and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
 and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
 </p>

 <p>The <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
 defines who the Go contributors&mdash;the people&mdash;are;
 the <a href="/AUTHORS"><code>AUTHORS</code></a> file defines
 who &ldquo;The Go Authors&rdquo;&mdash;the copyright holders&mdash;are.
 The Go developers at Google will update these files when submitting
 your first change.
 In order for them to do that, you need to have completed one of the
 contributor license agreements:
 <ul>
 <li>
 If you are the copyright holder, you will need to agree to the
 <a href="https://developers.google.com/open-source/cla/individual">individual
 contributor license agreement</a>, which can be completed online.
 </li>
 <li>
 If your organization is the copyright holder, the organization
 will need to agree to the
 <a href="https://developers.google.com/open-source/cla/corporate">corporate
 contributor license agreement</a>.
 (If the copyright holder for your code has already completed the
 agreement in connection with another Google open source project,
 it does not need to be completed again.)
 </li>
 </ul>

 <p>
 This rigmarole needs to be done only for your first submission.
 </p>

 <p>Code that you contribute should use the standard copyright header:</p>

 <pre>
 // Copyright 2015 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 </pre>

 <p>
 Files in the repository are copyright the year they are added. It is not
 necessary to update the copyright year on files that you change.
 </p>
	<!--{
	"Title": "Contribution Guidelines"
	}-->

	<h2 id="Introduction">Introduction</h2>

	<p>
	This document explains how to contribute changes to the Go project.
	It assumes you have followed the
	<a href="/doc/install/source">installation instructions</a> and
	have <a href="code.html">written and tested your code</a>.
	</p>

	<p>
	(Note that the <code>gccgo</code> frontend lives elsewhere;
	see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
	</p>

	<h2 id="Design">Discuss your design</h2>

	<p>
	The project welcomes submissions but please let everyone know what
	you're working on if you want it to become part of the main repository.
	</p>

	<p>
	Before undertaking to write something new for the Go project, send
	mail to the <a href="https://groups.google.com/group/golang-nuts">mailing
	list</a> to discuss what you plan to do. This gives everyone a
	chance to validate the design, helps prevent duplication of effort,
	and ensures that the idea fits inside the goals for the language
	and tools. It also guarantees that the design is sound before code
	is written; the code review tool is not the place for high-level
	discussions.
	</p>

	<p>
	In short, send mail before you code.
	And don't start the discussion by mailing a change list!
	</p>

	<h2 id="Testing">Testing redux</h2>

	<p>
	You've <a href="code.html">written and tested your code</a>, but
	before sending code out for review, run all the tests for the whole
	tree to make sure the changes don't break other packages or programs:
	</p>

	<pre>
	$ cd go/src
	$ ./all.bash
	</pre>

	<p>
	(To build under Windows use <code>all.bat</code>.)
	</p>

	<p>
	After running for a while, the command should print
	"<code>ALL</code> <code>TESTS</code> <code>PASSED</code>".
	</p>

	<h2 id="Code_review">Code review</h2>

	<p>
	Changes to Go must be reviewed before they are accepted,
	no matter who makes the change.
	A custom git command called <code>git-codereview</code>,
	discussed below, helps manage the code review process through a Google-hosted
	<a href="https://go-review.googlesource.com/">instance</a> of the code review
	system called <a href="https://code.google.com/p/gerrit/">Gerrit</a>.
	</p>

	<h3>Set up authentication for code review</h3>

	<p>
	Gerrit uses Google Accounts for authentication. If you don't have
	a Google Account, you can create an account which
	<a href="https://www.google.com/accounts/NewAccount">includes
	a new Gmail email account</a> or create an account associated
	<a href="https://accounts.google.com/SignUpWithoutGmail">with your existing
	email address</a>.
	</p>

	<p>
	The email address associated with the Google Account you use will be recorded in
	the <a href="https://go.googlesource.com/go/+log/">change log</a>
	and in the <a href="/CONTRIBUTORS">contributors file</a>.
	</p>

	<p>
	To set up your account in Gerrit, visit
	<a href="https://go.googlesource.com">go.googlesource.com</a>
	and click on "Generate Password" in the page's top right menu bar.
	</p>

	<p>
	You will be redirected to accounts.google.com to sign in.
	</p>

	<p>
	Once signed in, you are returned back to go.googlesource.com to "Configure Git".
	Follow the instructions on the page.
	(If you are on a Windows computer, you should instead follow the instructions
	in the yellow box to run the command.)
	</p>

	<p>
	Your secret authentication token is now in a <code>.gitcookie</code> file
	and Git is configured to use this file.
	</p>

	<h3>Register with Gerrit</h3>

	<p>
	Now that you have your authentication token,
	you need to register your account with Gerrit.
	To do this, visit
	<a href="https://go-review.googlesource.com/login/">
	go-review.googlesource.com/login/</a>. You will immediately be redirected
	to Google Accounts. Sign in using the same Google Account you used above.
	That is all that is required.
	</p>

	<h3>Install the git-codereview command</h3>

	<p>
	Now install the <code>git-codereview</code> command by running,
	</p>

	<pre>
	$ go get -u golang.org/x/review/git-codereview
	</pre>

	<p>
	Make sure <code>git-codereview</code> is installed in your shell path, so that the
	<code>git</code> command can find it. Check that
	</p>

	<pre>
	$ git codereview help
	</pre>

	<p>
	prints help text, not an error.
	</p>

	<p>
	Note to Git aficionados: The <code>git-codereview</code> command is not required to
	upload and manage Gerrit code reviews. For those who prefer plain Git, the text
	below gives the Git equivalent of each git-codereview command. If you do use plain
	Git, note that you still need the commit hooks that the git-codereview command
	configures; those hooks add a Gerrit <code>Change-Id</code> line to the commit
	message and check that all Go source files have been formatted with gofmt. Even
	if you intend to use plain Git for daily work, install the hooks in a new Git
	checkout by running <code>git-codereview</code> <code>hooks</code>.
	</p>

	<h3>Set up git aliases</h3>

	<p>
	The <code>git-codereview</code> command can be run directly from the shell
	by typing, for instance,
	</p>

	<pre>
	$ git codereview sync
	</pre>

	<p>
	but it is more convenient to set up aliases for <code>git-codereview</code>'s own
	subcommands, so that the above becomes,
	</p>

	<pre>
	$ git sync
	</pre>

	<p>
	The <code>git-codereview</code> subcommands have been chosen to be distinct from
	Git's own, so it's safe to do so.
	</p>

	<p>
	The aliases are optional, but in the rest of this document we will assume
	they are installed.
	To install them, copy this text into your Git configuration file
	(usually <code>.gitconfig</code> in your home directory):
	</p>

	<pre>
	[alias]
	change = codereview change
	gofmt = codereview gofmt
	mail = codereview mail
	pending = codereview pending
	submit = codereview submit
	sync = codereview sync
	</pre>

	<h3>Understanding the git-codereview command</h3>

	<p>After installing the <code>git-codereview</code> command, you can run</p>

	<pre>
	$ git codereview help
	</pre>

	<p>
	to learn more about its commands.
	You can also read the <a href="https://godoc.org/golang.org/x/review/git-codereview">command documentation</a>.
	</p>

	<h3>Switch to the master branch</h3>

	<p>
	Most Go installations use a release branch, but new changes should
	only be made based on the master branch.
	(They may be applied later to a release branch as part of the release process,
	but most contributors won't do this themselves.)
	Before making a change, make sure you start on the master branch:
	</p>

	<pre>
	$ git checkout master
	$ git sync
	</pre>

	<p>
	(In Git terms, <code>git</code> <code>sync</code> runs
	<code>git</code> <code>pull</code> <code>-r</code>.)
	</p>

	<h3>Make a change</h3>

	<p>
	The entire checked-out tree is writable.
	Once you have edited files, you must tell Git that they have been modified.
	You must also tell Git about any files that are added, removed, or renamed files.
	These operations are done with the usual Git commands,
	<code>git</code> <code>add</code>,
	<code>git</code> <code>rm</code>,
	and
	<code>git</code> <code>mv</code>.
	</p>

	<p>
	If you wish to checkpoint your work, or are ready to send the code out for review, run</p>

	<pre>
	$ git change <i><branch></i>
	</pre>

	<p>
	from any directory in your Go repository to commit the changes so far.
	The name <i><branch></i> is an arbitrary one you choose to identify the
	local branch containing your changes.
	</p>

	<p>
	(In Git terms, <code>git</code> <code>change</code> <code><branch></code>
	runs <code>git</code> <code>checkout</code> <code>-b</code> <code>branch</code>,
	then <code>git</code> <code>branch</code> <code>--set-upstream-to</code> <code>origin/master</code>,
	then <code>git</code> <code>commit</code>.)
	</p>

	<p>
	Git will open a change description file in your editor.
	(It uses the editor named by the <code>$EDITOR</code> environment variable,
	<code>vi</code> by default.)
	The file will look like:
	</p>

	<pre>

	# Please enter the commit message for your changes. Lines starting
	# with '#' will be ignored, and an empty message aborts the commit.
	# On branch foo
	# Changes not staged for commit:
	# modified: editedfile.go
	#
	</pre>

	<p>
	At the beginning of this file is a blank line; replace it
	with a thorough description of your change.
	The first line of the change description is conventionally a one-line
	summary of the change, prefixed by the primary affected package,
	and is used as the subject for code review mail.
	The rest of the
	description elaborates and should provide context for the
	change and explain what it does.
	If there is a helpful reference, mention it here.
	</p>

	<p>
	After editing, the template might now read:
	</p>

	<pre>
	math: improved Sin, Cos and Tan precision for very large arguments

	The existing implementation has poor numerical properties for
	large arguments, so use the McGillicutty algorithm to improve
	accuracy above 1e10.

	The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm

	Fixes #159

	# Please enter the commit message for your changes. Lines starting
	# with '#' will be ignored, and an empty message aborts the commit.
	# On branch foo
	# Changes not staged for commit:
	# modified: editedfile.go
	#
	</pre>

	<p>
	The commented section of the file lists all the modified files in your client.
	It is best to keep unrelated changes in different change lists,
	so if you see a file listed that should not be included, abort
	the command and move that file to a different branch.
	</p>

	<p>
	The special notation "Fixes #159" associates the change with issue 159 in the
	<a href="https://golang.org/issue/159">Go issue tracker</a>.
	When this change is eventually submitted, the issue
	tracker will automatically mark the issue as fixed.
	(There are several such conventions, described in detail in the
	<a href="https://help.github.com/articles/closing-issues-via-commit-messages/">GitHub Issue Tracker documentation</a>.)
	</p>

	<p>
	Once you have finished writing the commit message,
	save the file and exit the editor.
	</p>

	<p>
	If you wish to do more editing, re-stage your changes using
	<code>git</code> <code>add</code>, and then run
	</p>

	<pre>
	$ git change
	</pre>

	<p>
	to update the change description and incorporate the staged changes. The
	change description contains a <code>Change-Id</code> line near the bottom,
	added by a Git commit hook during the initial
	<code>git</code> <code>change</code>.
	That line is used by Gerrit to match successive uploads of the same change.
	Do not edit or delete it.
	</p>

	<p>
	(In Git terms, <code>git</code> <code>change</code> with no branch name
	runs <code>git</code> <code>commit</code> <code>--amend</code>.)
	</p>

	<h3>Mail the change for review</h3>

	<p>
	Once the change is ready, mail it out for review:
	</p>

	<pre>
	$ git mail
	</pre>

	<p>
	You can specify a reviewer or CC interested parties
	using the <code>-r</code> or <code>-cc</code> options.
	Both accept a comma-separated list of email addresses:
	</p>

	<pre>
	$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
	</pre>

	<p>
	Unless explicitly told otherwise, such as in the discussion leading
	up to sending in the change list, it's better not to specify a reviewer.
	All changes are automatically CC'ed to the
	<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
	mailing list.
	</p>

	<p>
	(In Git terms, <code>git</code> <code>mail</code> pushes the local committed
	changes to Gerrit using <code>git</code> <code>push</code> <code>origin</code>
	<code>HEAD:refs/for/master</code>.)
	</p>

	<p>
	If your change relates to an open issue, please add a comment to the issue
	announcing your proposed fix, including a link to your CL.
	</p>

	<p>
	The code review server assigns your change an issue number and URL,
	which <code>git</code> <code>mail</code> will print, something like:
	</p>

	<pre>
	remote: New Changes:
	remote: https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
	</pre>

	<h3>Reviewing code</h3>

	<p>
	Running <code>git</code> <code>mail</code> will send an email to you and the
	reviewers asking them to visit the issue's URL and make comments on the change.
	When done, the reviewer adds comments through the Gerrit user interface
	and clicks "Reply" to send comments back.
	You will receive a mail notification when this happens.
	You must reply through the web interface.
	(Unlike with the old Rietveld review system, replying by mail has no effect.)
	</p>

	<h3>Revise and upload</h3>

	<p>
	You must respond to review comments through the web interface.
	(Unlike with the old Rietveld review system, responding by mail has no effect.)
	</p>

	<p>
	When you have revised the code and are ready for another round of review,
	stage those changes and use <code>git</code> <code>change</code> to update the
	commit.
	To send the update change list for another round of review,
	run <code>git</code> <code>mail</code> again.
	</p>

	<p>
	The reviewer can comment on the new copy, and the process repeats.
	The reviewer approves the change by giving it a positive score
	(+1 or +2) and replying <code>LGTM</code>: looks good to me.
	</p>

	<p>
	You can see a list of your pending changes by running <code>git</code>
	<code>pending</code>, and switch between change branches with <code>git</code>
	<code>change</code> <code><i><branch></i></code>.
	</p>

	<h3>Synchronize your client</h3>

	<p>
	While you were working, others might have submitted changes to the repository.
	To update your local branch, run
	</p>

	<pre>
	$ git sync
	</pre>

	<p>
	(In git terms, <code>git</code> <code>sync</code> runs
	<code>git</code> <code>pull</code> <code>-r</code>.)
	</p>

	<p>
	If files you were editing have changed, Git does its best to merge the
	remote changes into your local changes.
	It may leave some files to merge by hand.
	</p>

	<p>
	For example, suppose you have edited <code>sin.go</code> but
	someone else has committed an independent change.
	When you run <code>git</code> <code>sync</code>,
	you will get the (scary-looking) output:

	<pre>
	$ git sync
	Failed to merge in the changes.
	Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
	The copy of the patch that failed is found in:
	/home/you/repo/.git/rebase-apply/patch

	When you have resolved this problem, run "git rebase --continue".
	If you prefer to skip this patch, run "git rebase --skip" instead.
	To check out the original branch and stop rebasing, run "git rebase --abort".
	</pre>

	<p>
	If this happens, run
	</p>

	<pre>
	$ git status
	</pre>

	<p>
	to see which files failed to merge.
	The output will look something like this:
	</p>

	<pre>
	rebase in progress; onto a24c3eb
	You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
	(fix conflicts and then run "git rebase --continue")
	(use "git rebase --skip" to skip this patch)
	(use "git rebase --abort" to check out the original branch)

	Unmerged paths:
	(use "git reset HEAD <file>..." to unstage)
	(use "git add <file>..." to mark resolution)

	<i>both modified: sin.go</i>
	</pre>

	<p>
	The only important part in that transcript is the italicized "both modified"
	line: Git failed to merge your changes with the conflicting change.
	When this happens, Git leaves both sets of edits in the file,
	with conflicts marked by <code><<<<<<<</code> and
	<code>>>>>>>></code>.
	It is now your job to edit the file to combine them.
	Continuing the example, searching for those strings in <code>sin.go</code>
	might turn up:
	</p>

	<pre>
	arg = scale(arg)
	<<<<<<< HEAD
	if arg < 1e9 {
	=======
	if arg &lh; 1e10 {
	>>>>>>> mcgillicutty
	largeReduce(arg)
	</pre>

	<p>
	Git doesn't show it, but suppose the original text that both edits
	started with was 1e8; you changed it to 1e10 and the other change to 1e9,
	so the correct answer might now be 1e10. First, edit the section
	to remove the markers and leave the correct code:
	</p>

	<pre>
	arg = scale(arg)
	if arg < 1e10 {
	largeReduce(arg)
	</pre>

	<p>
	Then tell Git that the conflict is resolved by running
	</p>

	<pre>
	$ git add sin.go
	</pre>

	<p>
	If you had been editing the file, say for debugging, but do not
	care to preserve your changes, you can run
	<code>git</code> <code>reset</code> <code>HEAD</code> <code>sin.go</code>
	to abandon your changes.
	Then run <code>git</code> <code>rebase</code> <code>--continue</code> to
	restore the change commit.
	</p>

	<h3>Reviewing code by others</h3>

	<p>
	You can import a change proposed by someone else into your local Git repository.
	On the Gerrit review page, click the "Download ▼" link in the upper right
	corner, copy the "Checkout" command and run it from your local Git repo.
	It should look something like this:
	</p>

	<pre>
	$ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
	</pre>

	<p>
	To revert, change back to the branch you were working in.
	</p>

	<h3>Submit the change after the review</h3>

	<p>
	After the code has been <code>LGTM</code>'ed, an approver may
	submit it to the master branch using the Gerrit UI.
	There is a "Submit" button on the web page for the change
	that appears once the change is approved (marked +2).
	</p>

	<p>
	This checks the change into the repository.
	The change description will include a link to the code review,
	and the code review will be updated with a link to the change
	in the repository.
	Since the method used to integrate the changes is "Cherry Pick",
	the commit hashes in the repository will be changed by
	the submit operation.
	</p>

	<h3>More information</h3>

	<p>
	In addition to the information here, the Go community maintains a <a href="https://golang.org/wiki/CodeReview">CodeReview</a> wiki page.
	Feel free to contribute to this page as you learn the review process.
	</p>

	<h2 id="copyright">Copyright</h2>

	<p>Files in the Go repository don't list author names,
	both to avoid clutter and to avoid having to keep the lists up to date.
	Instead, your name will appear in the
	<a href="https://golang.org/change">change log</a>
	and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
	and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
	</p>

	<p>The <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
	defines who the Go contributors—the people—are;
	the <a href="/AUTHORS"><code>AUTHORS</code></a> file defines
	who “The Go Authors”—the copyright holders—are.
	The Go developers at Google will update these files when submitting
	your first change.
	In order for them to do that, you need to have completed one of the
	contributor license agreements:
	<ul>
	<li>
	If you are the copyright holder, you will need to agree to the
	<a href="https://developers.google.com/open-source/cla/individual">individual
	contributor license agreement</a>, which can be completed online.
	</li>
	<li>
	If your organization is the copyright holder, the organization
	will need to agree to the
	<a href="https://developers.google.com/open-source/cla/corporate">corporate
	contributor license agreement</a>.
	(If the copyright holder for your code has already completed the
	agreement in connection with another Google open source project,
	it does not need to be completed again.)
	</li>
	</ul>

	<p>
	This rigmarole needs to be done only for your first submission.
	</p>

	<p>Code that you contribute should use the standard copyright header:</p>

	<pre>
	// Copyright 2015 The Go Authors. All rights reserved.
	// Use of this source code is governed by a BSD-style
	// license that can be found in the LICENSE file.
	</pre>

	<p>
	Files in the repository are copyright the year they are added. It is not
	necessary to update the copyright year on files that you change.
	</p>