Sometimes I want to get try bot results without checking out the
relevant branch.
R=agable@chromium.org
Bug:
Change-Id: I89d118962ee37b10d95cf4044b61a0f2234b7e60
Reviewed-on: https://chromium-review.googlesource.com/710500
Commit-Queue: Stefan Zager <szager@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
If -m option value starts with "luci.", most probably the user intends
to schedule a build on a LUCI bucket. Print an error message asking
the user to use -B option.
Bug: 749696
Change-Id: If7a038a1f629ee808e3261ae1c753e388bfea893
Reviewed-on: https://chromium-review.googlesource.com/707534
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Nodir Turakulov <nodir@chromium.org>
Previously, git-cl-diff went through a dance where it would create
a new branch, download the uploaded patch onto that branch, and
then diff against that. This had all sorts of problems: if you
aborted the command, it might leave you on that branch; if you have
local changes, they might get clobbered or the command would refuse
to run.
Now that we're in a Gerrit-only world, and patchsets are by definition
equivalent to commits, we can simply diff against whatever local commit
was last uploaded or, in a pinch, fetch the uploaded commit and diff
against that.
Bug: 759893
Change-Id: Ia4b93dcfb9b8aba85817e62731f68d6450026e75
Reviewed-on: https://chromium-review.googlesource.com/639915
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Since git-cl TBR always sets +1, it does not allow auto-submit where
using +2 score as approval. Let me make git-cl automatically adjust
to proper score.
Bug: 762425
Change-Id: I71fe1af1b8bf5e68d2509c60e8bf05024b6bdbb7
Reviewed-on: https://chromium-review.googlesource.com/680717
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
This allows a script to generate a sufficient list of owners (and
reviewers) for a given CL. Unlike the owners presubmit check and
the normal, interactive mode of `git-cl owners`, we do not print
the comments associated with an owner for each file, since
presumably a script doesn't care about them (and the comments
aren't in a particularly machine-parsable form, anyway).
This could be used by the WPT import scripts, and presumably
by roll scripts and other such things.
I didn't add a test for this because there appears to be no good
mechanism for testing top-level CMD functions in git_cl that
didn't end up just repeating the code mock-for-mock :(.
R: phajdan.jr@chromium.org
Change-Id: I3a9e6d117d6f4bafe938b07b028f119835c3e575
Reviewed-on: https://chromium-review.googlesource.com/648653
Reviewed-by: Paweł Hajdan Jr. <phajdan.jr@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
This adds support for the new urls (which contain the project) to
git-cl [description|checkout|issue|patch] and others.
Bug: 757602
Change-Id: I6e854a85e655e14daa7e4172ca938953778bf514
Reviewed-on: https://chromium-review.googlesource.com/634518
Commit-Queue: Andrii Shyshkalov <tandrii@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
This allows us to skip 'git cl format' for histograms.xml, which in
turn allows us to issue a presubmit error rather than a warning when
that file is malformatted, without running the formatting code twice.
The formatter is somewhat slow for this file, so it's helpful to avoid
duplicating that work.
BUG=none
TEST=none
R=iannucci@chromium.org
Change-Id: Ia86d45c7c56a9f89db34ca7175ef686589084f85
Reviewed-on: https://chromium-review.googlesource.com/569105
Commit-Queue: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Using self.GetDescription() uses the description from the web.
Given that the user is purposefully disassociating their current
branch from the review on the web, they may have already changed
the commit message. We shouldn't set it back.
Bug: 742730
Change-Id: I0545cb6288c332fd475d1de7fb302f71ee41a415
Reviewed-on: https://chromium-review.googlesource.com/578229
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
The actual flag is --send-mail. Also includes a fix
to publish these changes if a comment is included.
Bug: 740950
Change-Id: I38ca0a35c1364c8364eb0ef301137c04daede40b
Reviewed-on: https://chromium-review.googlesource.com/572033
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
In Rietveld, adding a comment to a change automatically
published it no matter what. In Gerrit, we need to explicitly
mark the change as Ready for Review. This CL adds a new
parameter to the wrapper methods around the SetReview
API so that they can mark changes as Ready.
Bug: 740950
Change-Id: Icb2ad7c5beb03a4760657a761841745f0d75514e
Reviewed-on: https://chromium-review.googlesource.com/572031
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Although git-cl-upload warns when uploading a new patchset
to a change owned by someone else, if the uploader has run
'git cl issue 0', then git-cl believes they'll be uploading
a new change, so it doesn't bother checking. However, once
the upload begins, Gerrit notices the Change-Id in the commit
message, and instead adds a new patchset to someone else's
review (if the uploader is a committer).
This change introduces some logic to git-cl-issue to also
remove any Change-Id from the commit message when a user
tries to clear the metadata about their branch.
Bug: 741648
Change-Id: I6c7c3b24a7fc09c68220c8200b732fbdf9cf1fd3
Reviewed-on: https://chromium-review.googlesource.com/568267
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Due to relaxation of when last paragraph of commit message is
is consider as containing footers, `git cl land` started removing
non-canonic footer lines from last paragraph if Git Numberer is enabled
on a repo. This only manifests in manual lands of Rietveld CLs or
bypassing code review entirely.
R=agable@chromium.org
Bug: 736852
Change-Id: I3972c590c3959974157ada9de9891a3c08bd385a
Reviewed-on: https://chromium-review.googlesource.com/562278
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Andrii Shyshkalov <tandrii@chromium.org>
It seems like some folks are confused by additional patchsets
after the first putting the change back into WIP mode. This
confusion is honestly understandable. Maybe we try only setting
it on the very first upload, and just controlling the notify
parameter for future patchsets.
Bug: 721836, 737675
Change-Id: If56e5c71e0c6b3b46c2e30ac0b6d80b878218181
Reviewed-on: https://chromium-review.googlesource.com/552779
Reviewed-by: Quinten Yearsley <qyearsley@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: smut <smut@google.com>
Commit-Queue: Aaron Gable <agable@chromium.org>
The previous CL forgot that the lack of '%wip' doesn't
mark a change ready-to-review, you have to explicitly pass
'%ready' in the refspec to do that.
TBR=tandrii@chromium.org
Bug: 721836
Change-Id: Iea82222d64edf1b73fefa9bca3feec4188e35ab3
Reviewed-on: https://chromium-review.googlesource.com/551005
Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Work-In-Progress is a new change flag that can be set on
Gerrit changes. While a change is in WIP mode, certain things
are different:
* It doesn't send emails except to the change owner
* The "Reply" button becomes "Start Review"
* When a change is moved out of WIP, it sends a special
"ready for review" message to any new reviewers
This is much more similar to the Rietveld model, where users
would "Publish" their changes for the reviewers to look at.
Bug: 721836
Change-Id: I3b9697e311fa176cb679ecefbfead9bb32b6afaf
Reviewed-on: https://chromium-review.googlesource.com/549015
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Reviewed-by: Quinten Yearsley <qyearsley@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
This is a partial revert of https://chromium-review.googlesource.com/c/527345/
Turns out more people were confused by the new behavior than
expected, so we're returning to "cherry-pick" being the default,
but supporting the collaboration workflow is important, so we're
adding a warning message and support for "reset --hard" behind a
pre-existing flag.
Bug: 723787
Change-Id: Ib6038a42e3bdcc0db93c1f32d759e9ff0e91a065
Reviewed-on: https://chromium-review.googlesource.com/538137
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
There's no reason not to, since it is pretty easy, and other
commands like "git cl patch" already do so.
Bug: 733715
Change-Id: I3396153ef11bfdbbf09b8a7f54f9a5b1047e290f
Reviewed-on: https://chromium-review.googlesource.com/537113
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
This CL changes the way that "git cl patch" behaves for Gerrit changes.
Previously, git-cl-patch behaved just like it did for Rietveld:
make sure you're on a branch, download the diff, apply it on top
of your branch. However, this causes problems with Gerrit. Namely,
when you upload a change to Gerrit, git-cl has to make sure that all
parents of your local change have previously been uploaded as well,
either as other changes or as commits already landed on the target
branch. But the method for "applying a patch" from Gerrit was to
cherry-pick it, and that changes the commit hash. So the resulting
commit would *not* have been uploaded to Gerrit. Thus, the
following routine didn't work with Gerrit:
$ git checkout -t origin/master -b your-work
$ git cl patch 123456
$ git checkout -tb my-work
$ #hack and commit
$ git cl upload
This would fail during the upload with a message saying that the
contents of 'your-work' hadn't been uploaded.
This CL fixes the situation by replacing the cherry-pick with
a hard reset. This means that the contents of the 'your-work'
branch will be *exactly* what was downloaded from Gerrit. Uploads
based on top of that commit will work just fine.
Finally, in a concession to some people who want 'git cl patch'
to actually apply a patch instead of performing a hard reset, if
the current branch contains local work, then rather than leaving
that work behind with a hard reset, we fall back to the old
cherry-pick behavior with a confirmation dialog and warning that
uploading will be hard.
Bug: 723787
Change-Id: I3ad164f6d3078bff00139d446bb8ce97738a1344
Reviewed-on: https://chromium-review.googlesource.com/527345
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
The logic for handling --title, --message, and the
commit message of the most recent commit was accidentally
doing this differently from how Rietveld had done them.
Bug: 728391
Change-Id: I70a46ccb470d790103f5d6bb745902595be28eee
Reviewed-on: https://chromium-review.googlesource.com/527339
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
This prevents TBR (self code-review) permissions from blocking
the CL from being uploaded at all. Instead, it will fully
upload, and then show a better error message after upload is
complete.
Bug: 729967
Change-Id: I55e3e98e200143076afcaab858064d9f5c62f8ef
Reviewed-on: https://chromium-review.googlesource.com/527325
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
This brings the gerrit version of "git cl comments" into line
with the Rietveld implementation by including file- and line-level
comments as well as top-level review comments. It requires an
extra API call to do so, so this may result in some slow-down, but
the result is worth it.
It formats the comments to match the formatting used in the
PolyGerrit UI, with the addition of visible URLs linking to
the comment since we can't hyperlink text in the terminal.
This CL also causes it to ignore messages and comments with
the 'autogenerated' tag, which are generally less interesting
and clutter the output.
Bug: 726514
Change-Id: I1fd939d90259b43886ddc209c0e727eab36cc9c9
Reviewed-on: https://chromium-review.googlesource.com/520722
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
For a bit of context, see the TODO in the code --
I think that the original intent of that TODO was that we to make
the way that CQ dry runs are triggered consistent, and also make
the behavior of dry runs consistent across different commands.
Change-Id: I80dfc31ade302a6af7fa84011e2871d416ea9c96
Reviewed-on: https://chromium-review.googlesource.com/518930
Commit-Queue: Quinten Yearsley <qyearsley@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
The private mode is a better fit for how we want private
(e.g. security-critical) changes to be reviewed. Draft
was simply a placeholder until private was ready for use,
which it now is.
Bug: 721880, 722627
Change-Id: Ib7b76c555437f4ddc7ab2b0e7ce5a9f9ee8be825
Reviewed-on: https://chromium-review.googlesource.com/513243
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrew Bonventre <andybons@chromium.org>
This information is redundant when using Gerrit,
and is well known to anyone still using Rietveld.
Change-Id: I03119a84edb67fd20fbe5e2a8e0f0975e69558ed
Reviewed-on: https://chromium-review.googlesource.com/510923
Reviewed-by: Andrew Bonventre <andybons@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Many WATCHLIST and codereview.settings files contain
large public email lists, which defeats the purpose
of private reviews.
R=tandrii@chromium.org
Bug: 721880
Change-Id: Ibb3f314f735b783e628f8cc1fc22c74e0df59f1c
Reviewed-on: https://chromium-review.googlesource.com/506489
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Stefan Zager
Nodir Turakulov
Aaron Gable
Yoshisato Yanagisawa
Edward Lemur
Dirk Pranke
Ilya Sherman
Andrii Shyshkalov
Anna Henningsen
Quinten Yearsley
Francois Doray