After adding the extension, hg help codereview
-will show documentation for its commands.
+will show documentation for its commands. As the codereview extension is only
+enabled for your checkout in $GOROOT, the remainder of this
+document assumes you are inside $GOROOT when issuing commands.
hg change will print, something like:
CL created: http://codereview.appspot.com/99999
+
If you need to re-edit the change description, or change the files included in the CL,
-run hg change 99999. Alternatively, you can use hg file 99999 somefile
-to add somefile to CL 99999, and use hg file -d 99999 somefile to remove
-somefile from the CL.
+run hg change 99999.
-Creating the change uploads a copy of the diff to the code review server, but it does not
-notify anyone about it. To do that, you need to run hg mail (see below).
+Alternatively, you can use
+
+$ hg file 99999 somefile ++ +
+to add somefile to CL 99999, and
+
+$ hg file -d 99999 somefile ++ +
+to remove somefile from the CL.
-You can see a list of your pending changes by running hg pending (hg p for short).
+A file may only belong to a single active CL at a time. hg file
+will issue a warning if a file is moved between changes.
While you were working, others might have submitted changes @@ -390,6 +407,12 @@ changes, but you may still need to run
+Creating or uploading the change uploads a copy of the diff to the code review server,
+but it does not notify anyone about it. To do that, you need to run hg mail
+(see below).
+
To send out a change for review, run hg mail using the change list number
assigned during hg change:
Note that -r and --cc cannot be spelled --r or -cc.
+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. +
You will probably revise your code in response to the reviewer comments. +
+You will probably revise your code in response to the reviewer comments. When
+you have done this, you can upload your change to the code review server
+without sending a notification by running hg upload using the change
+list number assigned during hg change
+
+$ hg upload 99999 ++ +
When you have revised the code and are ready for another round of review, run
@@ -445,11 +483,73 @@ The reviewer approves the change by replying with a mail that saysLGTM: looks good to me.
+
+You can see a list of your pending changes by running hg pending (hg p for short).
+
+You can import a CL proposed by someone else into your local Mercurial client
+by using the hg clpatch command. Running
+
+$ hg clpatch 99999 ++ +
+will apply the latest diff for CL 99999 to your working copy. If any of the
+files referenced in CL 99999 have local modifications, clpatch
+will refuse to apply the whole diff. Once applied, CL 99999 will show up in
+the output of hg pending and others.
+
+To revert a CL you have applied locally, use the hg revert
+command. Running
+
+$ hg revert @99999 ++ +
+will revert any files mentioned on CL 99999 to their original state. This can +be an effective way of reverting one CL revision and applying another. +
+ +
+Once the CL has been submitted, the next time you run hg sync
+it will be removed from your local pending list. Occasionally the pending list
+can get out of sync leaving stale references to closed or abandoned CLs.
+You can use hg change -D 99999 to remove the reference to CL 99999.
+
After the code has been LGTM'ed, it is time to submit
-it to the Mercurial repository.
+it to the Mercurial repository.
+
+If you are not a committer, you cannot submit the change directly.
+Instead a committer, usually the reviewer who said LGTM,
+will run:
+
+$ hg clpatch 99999 +$ hg submit 99999 ++ +The
submit command submits the code. You will be listed as the
+author, but the change message will also indicate who the committer was.
+Your local client will notice that the change has been submitted
+when you next run hg sync.
+
+
+If you are a committer, you can run:
@@ -475,30 +575,7 @@ $ hg submit 99999 local repository out of date; must sync before submit -
-If you are not a committer, you cannot submit the change directly.
-Instead, a committer, usually the reviewer who said LGTM,
-will run:
-
-$ hg clpatch 99999 -$ hg submit 99999 -- -
The clpatch command imports your change 99999 into
-the committer's local Mercurial client, at which point the committer
-can check or test the code more.
-(Anyone can run clpatch to try a change that
-has been uploaded to the code review server.)
-The submit command submits the code. You will be listed as the
-author, but the change message will also indicate who the committer was.
-Your local client will notice that the change has been submitted
-when you next run hg sync.
-
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. @@ -541,3 +618,8 @@ This rigmarole needs to be done only for your first submission. // Use of this source code is governed by a BSD-style // license that can be found in the LICENSE file. + +
+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. +