| commit | 90598e8208e5f792ce1b16e72ddc817791dd8708 | [log] [tgz] |
|---|---|---|
| author | Edwin Kempin <ekempin@google.com> | Thu Nov 17 13:24:35 2022 +0100 |
| committer | Edwin Kempin <ekempin@google.com> | Tue Nov 22 08:08:26 2022 +0100 |
| tree | b51347378fa20dd60799dc1d737b44c7ffd39dee | |
| parent | 23fc2a72064cdd442cee799726afc2490715d0a4 [diff] |
Fix GetRelated if multiple changes exist for the same commit The GetRelated REST endpoint returns all changes that are part of the same "group". The groups of a change are computed on upload. The most important rules are: 1. If a new change is uploaded and the base is not an open change, the group of the change is set to the commit SHA (starts a new group). 2. If a new change is uploaded and the base is an open change, the group of the change is set to the group of the base change (change is added to the existing group) If multiple changes are created for the same commit, but in different branches, it can happen that they get the exact same group assigned due to rule 1. All follow-up changes of these changes again get the same group assigned due to rule 2. When related changes are retrieved for any of the changes we query by project + groups which means the result wrongly includes changes from the other branches that have the same group, but which are actually not related. It's not deterministic which of the changes that were matched by the query are actually returned to the client. Since we do sorting based on a map some of the changes are dropped from the result due to a collision on the map key. As the result the shown related changes can be very confusing, e.g. A (branch Foo) > B (branch Bar) > C (branch Baz). Since changes from multiple branches are mixed it can also happen that a merged change is shown as depending on an open change (if a change series with the same group is merged in one branch but is still open in the other branch). To fix this we now query related changes by project + branch + groups (rather than just by project + groups). There is some special handling to split the query if it exceeds the maximum number of allowed predicates in a query (needed in case changes have an excessive number of groups). Since we have an additional predicate for the branch now, we must adapt the batch size there. Back at the time when the related changes logic was implemented it was not possible to create multiple changes for the same commit, but it's possible now by specifying a base [1] on upload. [1] https://gerrit-review.googlesource.com/Documentation/user-upload.html#base Signed-off-by: Edwin Kempin <ekempin@google.com> Release-Notes: Fix GetRelated if multiple changes for the same commit exist Change-Id: Ia8703c0dd1a669b203b2e6439be5658de3b52686 Bug: Google b/258852139
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update && apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 8 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-centos8
To run a Ubuntu 20.04 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-ubuntu20
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.