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>
Before, git cl creds-check expected `http.cookiefile` of git config
to have path without '~' which git understands on Linux/Mac.
R=machenbach@chromium.org
Bug: 719728
Change-Id: Ica1308b776b62bda7a8b85113c0c0df837c7d933
Reviewed-on: https://chromium-review.googlesource.com/501828
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Andrii Shyshkalov <tandrii@chromium.org>
The old system had two faults:
* It set reviewers and ccs via different mechanisms, which is confusing
* It set CCs with a single call for each, resulting in N separate emails,
with each email going to the uploader and all reviewers and all previous
CCs.
This new system just collects all reviewers and CCs, and sets them
in a single call. That call will fail if *any* of the individual
reviewers or ccs fail, so it also parses the response and retries with
only the ones which would have succeeded on their own. If that second
call fails, or the first fails in an unexpected way, it raises an
exception like normal
Bug: 710028
Change-Id: I1be508487a41f0b68f9c41908229b8f5342830a3
Reviewed-on: https://chromium-review.googlesource.com/479712
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Previously, if the branch structure was
origin/master
master [ 3 commits behind origin/master ]
my-branch [ 1 commit ahead of master ]
then git-cl would see that the upstream branch is master,
and decide to diff against origin/master instead. But that
diff would contain the contents of the three commits that
the local master branch hasn't caught up with yet. That's
not what we want.
This CL makes it so that basing on top of local master is
the same as basing on top of remote branches. Just like
when based on top of origin/master, it simply calculates
the merge-base with the parent commit (which is assumed
to be present in the remote), and uploads that diff.
Change-Id: I91caa30f6256a6e019e613dc5ff624734bca027e
Reviewed-on: https://chromium-review.googlesource.com/499307
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
This will allow git cl format to handle histograms.xml being
split into several files, and also adds support for UKM.
Bug:699328
Change-Id: I2bfbd333b78b679f69d7cb298f5adaf02f6a4dec
Reviewed-on: https://chromium-review.googlesource.com/483979
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Steven Holte <holte@chromium.org>
Aaron Gable
Edward Lemur
Dirk Pranke
Ilya Sherman
Andrii Shyshkalov
Anna Henningsen
Stefan Zager
Quinten Yearsley
Francois Doray
Steven Holte