Note that if you are working on the upcoming release
branch you have to point your extension path to a
copy of lib/codereview/codereview.py that won't change
as the repository flips between release-branch and default branch.
This warning should only apply to this one branch and only to rsc,
but you never know.
R=adg
CC=golang-dev
https://golang.org/cl/4446076
Set mailed bit correctly for self-clpatch.
Use repo.rollback correctly.
Allow leading spaces in some C code.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4438064
In the current codereview, if a patch was written against
a version of a file that had subsequently been edited,
hg clpatch would fail, even if the patch and the edits were
in different parts of the file. In this situation the reviewer
typically wrote back saying "please hg sync and hg mail
to update the patch".
This change rewrites the patch automatically, using the
same transformation that hg sync + hg mail would.
If the interim changes (since the patch was created)
affect the same line ranges as the patch, clpatch will
still refuse to apply it. But this CL should make
of the trivial conflicts we see just go away.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4377046
Right now if a Go developer makes a patch on one machine
and then clpatches it onto another machine, changes
subsequently made to the description are kept only
locally, under the assumption that you are running
clpatch because someone else wrote the CL, so you
don't have permission to update the web.
This change makes clpatch discard the "this was a
clpatch" information from the metadata when you
clpatch your own CLs from one machine to another.
This should eliminate some confusion (for example
in CL 4314054) but will no doubt introduce other
confusion.
R=golang-dev, r2
CC=golang-dev
https://golang.org/cl/4387041
Avoid passing the placeholder diff to hgpatch, so that
clpatch-ing an empty diff grabs the metadata and warns
about it being empty, rather than failing with a
hard-to-debug problem ("mkdir: no such file or dir",
no metadata, etc).
R=rsc
CC=golang-dev
https://golang.org/cl/4172060
Uploading go files on Windows aborts with gofmt: exceptions.ValueError:
close_fds is not supported on Windows platforms if you redirect stdin/stdout/stderr
R=rsc, mattn, Joe Poirier
CC=golang-dev
https://golang.org/cl/4025046
If a file pattern is given and matches files that look
like they need to be hg added or hg removed, offer to do so.
If a file pattern is given and matches files in another CL, warn.
If a file pattern doesn't match anything, point that out.
Vet first line of CL description.
Fixes#972.
R=adg, niemeyer
CC=bradfitzgo, golang-dev
https://golang.org/cl/4099042
End the charade (farce?) that we are using upload.py unaltered.
Cut all the unused stuff.
Indent using tabs to match the rest of the file.
Next: rewrite MercurialVCS to use mercurial package,
to avoid overhead of forking off a new hg command
multiple times for every file. And parallelize upload.
R=gri
CC=golang-dev
https://golang.org/cl/2009046
$ hg p
codereview disabled: cannot open /Users/rsc/g/go/src/pkg/goplan9.googlecode.com/hg/lib/codereview/codereview.cfg
$
R=dsymonds, r
CC=golang-dev
https://golang.org/cl/1998046
hg.parseurl now returns a two-value tuple; codereview.py expected 3.
Changed to merely take the first return value.
R=rsc, iant
CC=golang-dev
https://golang.org/cl/223087
