Gerrit Code Review - Searching Changes

Amount of time that has expired since the change was last updated with a review comment or new patch set. The age must be specified to include a unit suffix, for example -age:2d:

Changes assigned to the given user.

Changes whose attention set includes the given user.

Changes modified before the given 'TIME', inclusive. Must be in the format 2006-01-02[ 15:04:05[.890][ -0700]]; omitting the time defaults to 00:00:00 and omitting the timezone defaults to UTC.

Changes modified after the given 'TIME', inclusive. Must be in the format 2006-01-02[ 15:04:05[.890][ -0700]]; omitting the time defaults to 00:00:00 and omitting the timezone defaults to UTC.

Changes merged before the given 'TIME'. The matching behaviour is consistent with before:'TIME'.

Changes merged after the given 'TIME'. The matching behaviour is consistent with after:'TIME'.

Either a legacy numerical 'ID' such as 15183, or a newer style Change-Id that was scraped out of the commit message.

Changes that conflict with change 'ID'. Change 'ID' can be specified as a legacy numerical 'ID' such as 15183, or a newer style Change-Id that was scraped out of the commit message.

Changes which match the specified USER’s destination named 'NAME'. If 'USER' is unspecified, the current user is used. The named destinations can be publicly accessible by other users. (see Named Destinations).

Changes originally submitted by 'USER'. The special case of owner:self will find changes owned by the caller.

Changes originally submitted by a user in 'GROUP'.

Changes where the latest patch set was uploaded by 'USER'. The special case of uploader:self will find changes uploaded by the caller.

Changes where the latest patch set was uploaded by a user in 'GROUP'.

Changes which match the specified USER’s query named 'NAME'. If 'USER' is unspecified, the current user is used. The named queries can be publicly accessible by other users. (see Named Queries).

Changes that have been, or need to be, reviewed by 'USER'. The special case of reviewer:self will find changes where the caller has been added as a reviewer.

Changes that have the given user CC’ed on them. The special case of cc:self will find changes where the caller has been CC’ed.

Changes that revert the change specified by the numeric 'ID'.

Changes that have the specified submission 'ID'.

Changes that have been, or need to be, reviewed by a user in 'GROUP'.

Changes where 'SHA-1' is one of the patch sets of the change.

Changes occurring in 'PROJECT'. If 'PROJECT' starts with ^ it matches project names by regular expression. The dk.brics.automaton library is used for evaluation of such patterns.

Changes occurring in projects starting with 'PREFIX'.

Changes occurring in 'PROJECT' or in one of the child projects of 'PROJECT'.

Changes occurring in 'REPOSITORY'. If 'REPOSITORY' starts with ^ it matches repository names by regular expression. The dk.brics.automaton library is used for evaluation of such patterns.

Changes occurring in repositories starting with 'PREFIX'.

Changes occurring in 'REPOSITORY' or in one of the child repositories of 'REPOSITORY'.

Changes for 'BRANCH'. The branch name is either the short name shown in the web interface or the full name of the destination branch with the traditional 'refs/heads/' prefix.

If 'BRANCH' starts with ^ it matches branch names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns.

Changes whose designated topic contains 'TOPIC', using a full-text search.

If 'TOPIC' starts with ^ it matches topic names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns.

Changes whose designated topic matches 'TOPIC' exactly. This is often combined with 'branch:' and 'project:' operators to select all related changes in a series.

Changes where any hashtag contains 'HASHTAG', using a full-text search.

If 'HASHTAG' starts with ^ it matches hashtag names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns.

Changes whose hashtag matches 'HASHTAG'. The match is case-insensitive.

Changes which were created using the 'cherry-pick' functionality and whose source change number matches 'CHANGE' and source patchset number matches 'PATCHSET'. Note that 'PATCHSET' is optional. For example, a cherrypickof:12345 matches all changes which were cherry-picked from change 12345 and cherrypickof:12345,2 matches all changes which were cherry-picked from the 2nd patchset of change 12345.

Changes where the destination branch is exactly the given 'REF' name. Since 'REF' is absolute from the top of the repository it must start with 'refs/'.

If 'REF' starts with ^ it matches reference names by regular expression patterns. The dk.brics.automaton library is used for evaluation of such patterns.

Search for changes whose commit message contains 'ID' and matches one or more of the trackingid sections in the server’s configuration file. This is typically used to search for changes that fix a bug or defect by the issue tracking system’s issue identifier.

Matches changes where the approval score 'VALUE' has been set during a review. See labels below for more detail on the format of the argument.

Changes that match 'MESSAGE' arbitrary string in the commit message body.

Changes that match 'TEXT' string in any comment left by a reviewer.

Matches any change touching file at 'PATH'. By default exact path matching is used, but regular expressions can be enabled by starting with ^. For example, to match all XML files use file:"^.*\.xml$". The dk.brics.automaton library is used for the evaluation of such patterns.

The ^ required at the beginning of the regular expression not only denotes a regular expression, but it also has the usual meaning of anchoring the match to the start of the string. To match all Java files, use file:^.*\.java.

The entire regular expression pattern, including the ^ character, should be double quoted. For example, to match all XML files named like 'name1.xml', 'name2.xml', and 'name3.xml' use file:"^name[1-3].xml".

Slash ('/') is used path separator.

More examples:

Matches any change touching a file containing the path component 'NAME'. For example a file:src will match changes that modify files named gerrit-server/src/main/java/Foo.java. Name matching is exact match, file:Foo.java finds any change touching a file named exactly Foo.java and does not match AbstractFoo.java.

Regular expression matching can be enabled by starting the string with ^. In this mode file: is an alias of path: (see above).

Matches any change touching a file with extension 'EXT', case-insensitive. The extension is defined as the portion of the filename following the final .. Files with no . in their name have no extension and can be matched by an empty string.

Matches any change touching only files with extensions that are listed in 'EXT_LIST' (comma-separated list). The matching is done case-insensitive. An extension is defined as the portion of the filename following the final .. Files with no . in their name have no extension and can be matched by an empty string.

Matches any change where the current patch set touches a file in the directory 'DIR'. The matching is done case-insensitive. 'DIR' can be a full directory name, a directory prefix or any combination of intermediate directory segments. E.g. a change that touches a file in the directory 'a/b/c' matches for 'a/b/c', 'a', 'a/b', 'b', 'b/c' and 'c'.

Slash ('/') is used path separator. Leading and trailing slashes are allowed but are not mandatory.

If 'DIR' starts with ^ it matches directories and directory segments by regular expression. The dk.brics.automaton library is used for evaluation of such patterns.

Matches any change that has 'FOOTER' as footer in the commit message of the current patch set. 'FOOTER' can be specified verbatim ('<key>: <value>', must be quoted) or as '<key>=<value>'. The matching is done case-insensitive.

Matches any change that was starred by the current user with the label 'LABEL'.

E.g. if changes that are not interesting are marked with an ignore star, they could be filtered out by '-star:ignore'.

'star:star' is the same as 'has:star' and 'is:starred'.

True if there is a draft comment saved by the current user.

Same as 'is:starred' and 'star:star', true if the change has been starred by the current user with the default label.

True if the change has inline edit created by the current user.

True if the change has unresolved comments.

True if the change has attention by the current user.

True if the change has an assignee.

Same as 'has:star', true if the change has been starred by the current user with the default label.

True if the change does not have an assignee.

True if the change has attention by the current user.

True if this change matches one of the current user’s watch filters, and thus is likely to notify the user when it updates.

True if any user has commented on the change more recently than the last update (comment or patch set) from the change owner.

True on any change where the current user is the change owner. Same as owner:self.

True on any change where the current user is the uploader of the latest patch set. Same as uploader:self.

True on any change where the current user is a reviewer. Same as reviewer:self.

True on any change where the current user is in CC. Same as cc:self.

True if the change is open.

True if the change is either merged or abandoned.

Same as status:'STATE'.

True if the change is submittable according to the submit rules for the project, for example if all necessary labels have been voted on.

This operator only takes into account one change at a time, not any related changes, and does not guarantee that the submit button will appear for matching changes. To check whether a submit button appears, use the Get Revision Actions API.

Equivalent to submittable:ok.

True if the change has no merge conflicts and could be merged into its destination branch.

Mergeability of abandoned changes is not computed. This operator will not find any abandoned but mergeable changes.

This operator only works if Gerrit indexes 'mergeable'. See change.mergeabilityComputationBehavior for details.

True if the change is ignored. Same as star:ignore.

True if the change is private, ie. only visible to owner and its reviewers.

True if the change is Work In Progress.

True if the change is a merge commit.

True if the change is a cherrypick of an another change.

True if the change state is 'review in progress'.

Same as 'is:reviewed', matches if any user has commented on the change more recently than the last update (comment or patch set) from the change owner.

True if the change is either 'merged' or 'abandoned'.

Change has been merged into the branch.

Change has been abandoned.

True if the number of lines added/deleted/changed satisfies the given relation for the given number of lines.

For example, added:>50 will be true for any change which adds at least 50 lines.

Valid relations are >=, >, <=, <, or no relation, which will match if the number of lines is exactly equal.

Changes containing a top-level or inline comment by 'USER'. The special case of commentby:self will find changes where the caller has commented.

Changes containing a top-level or inline comment by 'USER', or owned by 'USER'. Equivalent to (owner:USER OR commentby:USER).

Changes where 'USER' has commented on the change more recently than the last update (comment or patch set) from the change owner.

Changes where 'AUTHOR' is the author of the current patch set. 'AUTHOR' may be the author’s exact email address, or part of the name or email address. The special case of author:self will find changes authored by the caller.

Changes where 'COMMITTER' is the committer of the current patch set. 'COMMITTER' may be the committer’s exact email address, or part of the name or email address. The special case of committer:self will find changes committed by the caller.

Changes having the given submit record status after applying submit rules. Valid statuses are in the status field of SubmitRecord. This operator only applies to the top-level status; individual label statuses can be searched by label.

Changes where 'SUBMIT_RULE_NAME' returns a submit record with status in {OK, FORCED}. This means that the submit rule has passed and is not blocking the change submission. 'SUBMIT_RULE_NAME' should be in the form of '$plugin_name~$rule_name'. For gerrit core rules, 'SUBMIT_RULE_NAME' should be in the form of '$rule_name' (example: DefaultSubmitRule), or 'gerrit~$rule_name' (example: gerrit~DefaultSubmitRule).

Changes where 'SUBMIT_RULE_NAME' returns a submit record with status equals to 'STATUS'. The status can be any of the statuses that are documented for the status field of SubmitRecord.

True if the number of unresolved comments satisfies the given relation for the given number.

For example, unresolved:>0 will be true for any change which has at least one unresolved comment while unresolved:0 will be true for any change which has all comments resolved.

Valid relations are >=, >, <=, <, or no relation, which will match if the number of unresolved comments is exactly equal.

Matches changes where there is at least one +2 score for Code-Review. The + prefix is optional for positive score values. If the + is used, the = operator is optional.

Matches changes where there is at least one -2 score for Code-Review. Because the negative sign is required, the = operator is optional.

Matches changes where there is at least one +1 score for Code-Review. Scores of +2 are not matched, even though they are higher.

Matches changes with either a +1, +2, or any higher score.

Instead of a numeric vote, you can provide a label status corresponding to one of the fields in the SubmitRecord REST API entity.

Matches changes with either a -1, -2, or any lower score.

Matches changes with label voted with the highest possible score.

Matches changes with label voted with the lowest possible score.

Matches changes with label voted with any score.

Matches changes where the submit rules indicate that a label named Non-Author-Code-Review is needed. (See the Prolog Cookbook for how this label can be configured.)

Matches changes with a +2 code review where the reviewer or group is aname.

Matches changes with a +2 code review where the reviewer is jsmith.

The special "owner" parameter corresponds to the change owner. Matches all changes that have a +2 vote from the change owner.

The special "non_uploader" parameter corresponds to any user who’s not the uploader of the latest patchset. Matches all changes that have a +2 vote from a non upoader.

Matches changes with a +1 code review where the reviewer is in the ldap/linux.workflow group.

Matches changes that are ready to be submitted according to one common label configuration. (For a more general check, use submittable:ok.)

Changes that are blocked from submission due to a blocking score.

Matches changes that are visible to 'USER' or to anyone who is a member of 'GROUP'. Here group names may be specified as either an internal group name, or if LDAP is being used, an external LDAP group name. The value may be wrapped in double quotes to include spaces or other special characters. For example, to match an LDAP group: visibleto:"CN=Developers, DC=example, DC=com".

This operator may be useful to test access control rules, however a change can only be matched if both the current user and the supplied user or group can see it. This is due to the implicit 'is:visible' clause that is always added by the server.

Magical internal flag to prove the current user has access to read the change. This flag is always added to any query.

Limit the returned results to no more than 'CNT' records. This is automatically set to the page size configured in the current user’s preferences. Including it in a web query may lead to unpredictable results with regards to pagination.