The diff between two patch sets contains hunks which weren't
introduced by either patch set if a rebase occurred between those
patch sets. Previous optimizations for this case simply omitted all
files which aren't touched by either of the patch sets.
This change goes one step further: All hunks which can clearly be
identified as being introduced by a rebase are marked. In case of
doubt (e.g. they overlap with a regular hunk), they aren't marked.
To be consistent with the previous behavior, we exclude all files from
the result which only contain hunks due to rebase. In some cases (e.g.
a patch set touches 'fileA' but all identified hunks were introduced
by the rebase), this rule can be stricter than the previously mentioned
(as the previous rule would still show file 'fileA' but we exclude it
now).
Hunks which are introduced by a rebase are identified by computing
the diff between the parents of the two patch sets and transforming
the result to differences in terms of treeA of patch set A and treeB
of patch set B. This follows a suggestion which was posted as a comment
(https://gerrit-review.googlesource.com/c/33091/5//COMMIT_MSG#7) in
change I63d3a21ad4f.
As we always determine which hunks are introduced by a rebase when
two commits are explicitly specified which don't share a common
parent, we will determine those hunks even when we compute the
diff between the parents of the patch sets provided that those
parents fulfill the condition of being separated by a rebase. Those
situations should be rare and hence we refrain from adding
optimizations for this case for the moment.
Bug: Issue 217
Change-Id: If06381d506d360f0e3d24d078dcb54692698e766
The loadJARs method throws an exception if the class loader which
needs to be extended is not an URLClassLoader. However, there is
no reason to fail when there are not jars to load.
Change-Id: I263384af81e7af1e2e8d8e0a3aee428f029c9d35
Add GlobalPermission enum mapping the simple boolean
GlobalCapabilities to be checked by PermissionBackend.
Rewrite GetCapabilities handler in terms of this API.
Change-Id: Ie06a4f6b18b7bdfabbaa58c6aa9becbc1d9b6136
Private changes are only visible to owner, reviewers and users with the
configured permission. This lets users stage changes without
advertising their change, and conduct sensitive reviews (eg. security)
mong a small group.
- Add Private field to change in ReviewDb
- Check visibility for private changes
- Add permission that allows users to see all private changes
- Add Private Footer to NoteDb
- Add field for private changes to index and QueryBuilder
- Add REST endpoints to Mark/Unmark private change
- VisibleRefsFilter filters private changes
- GWT UI: Mark/Unmark change as private and show private label
- GWT UI: Show 'status (Private)' in ChangeTable.
- Support to control privacy of a change on push
- Add tests for reviewer visibility and new permission
- Add tests for query by private
- Add tests for advertised references
- Add user documentation in intro-user
To push a private change or to turn a change private on push the
'private' option can be specified:
git push host HEAD:refs/for/master%private
Removing the privacy flag should not happen accidentally, but should be
a very explicit action. This is why omitting the 'private' option when
pushing updates to a private change doesn't remove the privacy flag on
the change. To remove the privacy flag from a change on push the
'remove-private' option can be used:
git push host HEAD:refs/for/master%remove-private
Change-Id: Ib2b26ea19c0286cff9c05754b0875f61e5e9fceb
Signed-off-by: Edwin Kempin <ekempin@google.com>
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Patrick Hiesel <hiesel@google.com>
Signed-off-by: Changcheng Xiao <xchangcheng@google.com>
Signed-off-by: Alice Kober-Sotzek <aliceks@google.com>
java.file.nio.Path implements Iterable<Path>, and provides an iterator
over the name elements of the path. Declaring a parameter of type
Iterable<Path> is not recommended as it allows callers to pass either
an Iterable of Paths, or a single Path. Using Collection<Path>
prevents callers from accidentally passing a single Path.
Change-Id: Iade69324698adaac7f2f50e1c97f956397cf11e4
With this change, users can delete their own (open or abandoned)
changes if an administrator grants them the permission
'Delete Own Changes'. Administrators don't require this permission.
Change-Id: I0de15167c12bc004efb40f80df6e600d7a4d3e76
MyIdentitiesScreen has been migrated to REST API by [1]. The old RPC
backend will not be used anymore and thus can be removed.
[1] https://gerrit-review.googlesource.com/#/c/95952/
Change-Id: I7d2b255b1ea7df455656cb8a4410cb0f279416d2
Having a standard tool for formatting saves reviewers' valuable time.
google-java-format is Google's standard formatter and is somewhat
inspired by gofmt[1]. This commit formats everything using
google-java-format version 1.2.
The downside of this one-off formatting is breaking blame. This can be
somewhat hacked around with a tool like git-hyper-blame[2], but it's
definitely not optimal until/unless this kind of feature makes its way
to git core.
Not in this change:
* Tool support, e.g. Eclipse. The command must be run manually [3].
* Documentation of best practice, e.g. new 100-column default.
[1] https://talks.golang.org/2015/gofmt-en.slide#3
[2] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[3] git ls-files | grep java$ | xargs google-java-format -i
Change-Id: Id5f3c6de95ce0b68b41f0a478b5c99a93675aaa3
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
AccountInfoCache was populated but nobody used it.
This was the last usage of AccountInfoCache, hence it can be removed
now.
Change-Id: I429e3e10bcd3b0148a272ec45d62c3babc80be1f
Signed-off-by: Edwin Kempin <ekempin@google.com>
* submodules:
* Update plugins/replication from branch 'master'
- Remove test prefix from test methods in replication plugin
We previously used 'test' to prefix tests but have decided to stop this.
This change removes the prefix from all test code.
Change-Id: I42e6191ece7872f4647e425e3ca0acf8c6452412
Reformat the Bazel build files with the buildifier tool [1].
The style is different for Bazel files. Most notably, indentation level
is 4 spaces instead of 2, and " is used instead of '.
[1] https://github.com/bazelbuild/buildifier
Change-Id: I95c0c6f11b6d76572797853b4ebb5cee5ebd3c98
We previously used 'test' to prefix tests but have decided to stop this.
This change removes the prefix from all test code.
Change-Id: I229a36751adc6a87fbae8d6f373671e141529496
Now, that: [1] is fixed and 0.4.1 is released that includes the fix we
can re-enable the auto_value tests again.
* [1] https://github.com/bazelbuild/bazel/issues/2044
Change-Id: I19cd699148290ac51d96035dd8c70562ef96ff76
For common labels like Code-Review and Verified, it still makes sense
to allow voting after submission, so keep the default as true. For
others, such as a label to trigger CI, it doesn't.
Bug: Issue 4942
Change-Id: I01a6281c11ee13bec9a6c8a2568b18ddd4eaccf4
Due to Bazel 0.4.0 incompatibility with auto-value 1.4-rc1, that was
recently upgraded to overcome integer overflow bug in hashCode()
method reported by Bazel 0.4.0, temporarily disable auto-value test.
Consider to enable it again, when this bug was fixed and new Bazel
version is released.
[1] https://github.com/bazelbuild/bazel/issues/2044
Change-Id: Id3d59908a2721031688645d2a3b039e227e54eca
For negative-only labels such as [1] editing access rights failed with
a TypeError in the GWT UI. This was because the max value was returned
as null, rather than the actual max value.
[1]
[label "Code-Review-Details"]
function = NoOp
value = -3 Bad technique choice
value = -2 Implementation problem
value = -1 Need to rebase
value = 0 No details
defaultValue = 0
Bug: Issue 4814
Change-Id: Iefa854ac3675a1592802e8ecbe20641ff8b79a3e
Signed-off-by: Edwin Kempin <ekempin@google.com>
In changes involving C++, *.h files should appear before their
corresponding *.cc file, although their lexicographic order is the
reverse. With this change, the relative order of *.h and *.cpp file
pairs in file groups of change comment emails is corrected.
Bug: Issue 4586
Change-Id: Ic9618a07167bde570bdfeb0ea54721c763034863
We can quickly evaluate labels and the submittable bit in ChangeJson
if we store the full submit records in the index. We would also like
to be able to search for submittable changes, i.e. changes that pass
the submit rule evaluator. Support this with a triumvirate of new
fields.
We now support `is:submittable` and `submit:STATUS` operators, as well
as a new flavor of `label:` that takes a submit record label status
rather than a numeric vote. These allow for more precise queries than
some of the heuristics that were previously documented in the search
docs.
Change-Id: Ie8a185a7cdae998be168900186fb64905246e7cf
There are 3 classes that represent an inline comment:
- CommentInfo represents an inline comment in the REST API
- PatchLineComment represents an inline comment in ReviewDb
- RevisionNote.Comment represents an inline comment in NoteDb
To support robot comments CommentInfo and RevisionNote.Comment must be
extended so that the additional fields that are specific for robot
comments can be supported. PatchLineComment should not be touched
since robot comments will only be supported with NoteDb, but not with
ReviewDb.
At the moment PatchLineComment is also used to represent inline
comments in all middle layers and in all utility classes that deal
with inline comments. This means if NoteDb is used, inline comments
come in over REST as CommentInfo, then they are converted into
PatchLineComment and for storing them in NoteDb they are converted to
RevisionNote.Comment. The intermediate transformation to
PatchLineComment is bad for implementing robot comments, since this
class should stay unchanged.
To fix this RevisionNote.Comment is extracted into an own Comment
class and then Comment is used instead of PatchLineComment in the
middle layer. This means when NoteDb is used, inline comments are only
converted once, from CommentInfo to Comment. Both types will have
extensions for robot comments (by subtypes).
For storing inline comments in ReviewDb inline comments are converted
from CommentInfo to Comment to PatchLineComment. This is better than
having the double-conversion for NoteDb, because ReviewDb will be
removed in favour of NoteDb. This means when ReviewDb is removed
PatchLineComment can then easily be deleted, as it's no longer used
all over the codebase, but only in the ReviewDb layer.
Change-Id: I53481e8231e04aeca5b924e409e97b0f1d53f516
Signed-off-by: Edwin Kempin <ekempin@google.com>
Permission deciding who is able to edit the assignee of a change.
Besides the users with edit assignee permission change owner, ref owner, and
the currently assigned user are allowed to change the assignee of a change.
Change-Id: I7cbc950c66b3d5f1e931d5f8d985d8112682971f
This version fixed a major issue: [1] that was a reason of frustration
of many plugin developers: Not cache sources files under symbolic link.
Now for all such source files, the warning is issued:
"
Disabling caching for target //plugins/wip:wip__plugin, because one or
more input files are under a symbolic link
({plugins/wip=/home/davido/projects/wip}). This will severely impact
performance! To resolve this, use separate rules and declare
dependencies instead of using symbolic links.
"
To suppress this warning we add project.allow_symlink option. This
doesn't have any impact for gerrit core but silences the warning above
when plugins are built in gerrit tree mode.
As pointed out in this issue: [2], we are using some artifacts as source
to the java_library() rule as well as binary_jar for prebuilt_ja rule.
To avoid the warning, we rename sources to have "-sources.jar" suffix
and we rename *.zip to end with .jar in other places.
"
Assuming edit.src.zip is a JAR and renaming to edit.src.jar in
//gerrit-patch-jgit:edit_src. Change the extension of the binary_jar to
'.jar' to remove this warning.
"
source_under_test attribute was removed from java_test() rule.
Replication and cookbook-plugin are updated as well.
local.properties support was removed, but we use it only for download
process customization in our own python script, so that we can keep it
usage and not need to move it to .buckconfig.local.
[1] https://github.com/facebook/buck/issues/341
[2] https://github.com/facebook/buck/issues/855
Change-Id: Idf76cc71c21df43e808179b645f9175767b322a8
Each tag type requires a special permission for the tag creation:
- Lightweight tags require 'Create Reference'
- Annontated tags require 'Push Annotated Tag'
- Signed tags require 'Push Signed Tag'
This naming is inconsistent and may be confusing. E.g. whether tags
can be updated is controlled by the 'Push' permission on 'refs/tags/*'
and not by the 'Push Annotated/Signed Tag' permission, as some users
might expect.
This change includes a schema migration that renames the permissions
for creating annotated/signed tags.
Permission rules in project.config that use the old names are still
respected. They are automatically converted when the project config is
saved the next time. This is needed so that multi-master sites can do
a multi-step-migration:
1. First upgrade all hosts to the new binary:
Projects may still contain permissions with the old names,
new permissions are saved with the new names.
2. Run a background job on all hosts that migrates the permissions for
all projects to the new names:
Projects do not contain permissions with the old names,
new permissions are saved with the new names.
3. Upgrade all hosts to a binary that doesn't respect the old names
anymore.
The migration for schema 130 is rewritten because ProjectConfig no
longer allows to change the force flag for 'pushTag' without
converting it to 'createTag'.
Change-Id: I839be24f82a908b5184f15e746f3588a0d397b7e
Signed-off-by: Edwin Kempin <ekempin@google.com>
This new permission allows users to delete branches and tags, without
allowing them to push branches and tags for new commits and thus
bypass code review, as it would be possible when force push would be
granted.
Bug: Issue 2179
Change-Id: I678650570ed2ce14fc1784fc7766b8ddbe7f9729
Signed-off-by: Edwin Kempin <ekempin@google.com>
Introduce new configuration option (gerrit.canLoadInIFrame) to allow
loading Gerrit in IFrame. By default it is set to 'false' to keep
current behavior.
Change-Id: Ie13b6141a9dfb8a18348fc778fb5f6083f95bd14
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
This eases the way of handling many different branches for the
superproject subscription. As the superproject subscriptions
are not yet in a release, we can still play around with them.
When a user sees "refs = refs/heads/*:refs/heads/*" they cannot tell
whether this is 1:1 matching or any match to any match without
consulting the documentation. Differentiate the matching
strategy by keys, such that we have "all = <refspec>" as well
as "matching = <refspec>".
The "all" key implies there is no interaction between the
wildcards on the left and right side, e.g.
all=refs/heads/*:refs/heads*
indicates that any branch can be subscribed to any other branch
in the given superproject.
"matching" however substitutes the wildcard on the right
with the captured value on the left.
matching=refs/heads/*:refs/heads*
allows a subscription of refs/heads/foo in the submodule to the
refs/heads/foo in the superproject.
Change-Id: I84d3a72c00f76570798880adf54ce56f974466ff
There are two problems with the current code:
1) the OR operator must be in capital letters
2) the OR operator is not a prefix operator, but an infix operator.
Change-Id: Icf91285096bd65753948c55578f86d9e80a4d13b
Signed-off-by: Stefan Beller <sbeller@google.com>
This change makes the topic link behavior similar to the behavior
branch link, which only shows the same status of changes for the
target branch. However when querying for new changes, it is also
useful to see what has already been done in the given topic. When
looking searching for changes of the same topic from a merged change
it is also useful to see what is still pending.
So in case of {NEW, MERGED} changes we search for both states.
Change-Id: I86f091d6afefbb4bef8bd24245edb64bb9a16f53
This is an atomic change that can be imported prior to a schema
migration. The change 78779 depends on this.
Change-Id: Ibba941ef54104a29d0e12b8307f74b7c0b385b93
To run the tests:
bazel test //...
To build the Gerrit plugin API, run:
bazel build gerrit-plugin-api:plugin-api_deploy.jar
To build the Gerrit extension API, run:
bazel build gerrit-extension-api:extension-api_deploy.jar
TODOs:
Licenses
Reduce visibility (all public for now)
Generate HTML Documentation
Core plugins
gerrit_plugin() rule to build plugins in tree and standalone modes
GWT UI (only gwt_module() skylark rule is provided, no gwt_binary())
PolyGerrit UI
WAR
Publish artifacts to Maven Central
Ask Bazel team to add Gerrit to their CI on ci.bazel.io
Contributed-By: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I9a86e670882a44a5c966579cdeb8ed79b1590de3
