| commit | 4c11544ba8c7170c21c8ad9124ecf9c82e57e096 | [log] [tgz] |
|---|---|---|
| author | Youssef Elghareeb <ghareeb@google.com> | Thu Jun 15 18:16:42 2023 +0200 |
| committer | Youssef Elghareeb <ghareeb@google.com> | Wed Jun 21 15:46:55 2023 +0200 |
| tree | 53a5ccc912a35229a2275eae1213b3f2f280cd1f | |
| parent | 847ab1456bda4a77c345838617b21370c4f51537 [diff] |
Add the 'branch' as a field of RevisionInfo Currently the branch field is only part of the ChangeInfo/ChangeData, however the target branch can be different if the change is moved between patchsets. We keep history of the target branch changes in NoteDb. In this change, we parse and set the 'branch' as a new field in PatchSet. We also surface the 'branch' field on the API in RevisionJson. A note on compatibility: PatchSet is an entity that's serialized to proto (See PatchSetProtoConverter) in two places: 1) in ChangeField to be stored in the change index. 2) as a field in ChangeNotesState, then stored as value in ChangeNotesCache. For [1], until we upgrade the version of the change index, existing patchsets stored in the index will not have the new 'branch' field set, hence any requests for patchsets data that go through the change index will not have the `branch` field set. If the per-patch-set branch does not exist, we only set the branch value to the per-change value if this is the last patch-set. Otherwise, the branch field will be null. For [2], we increased the cache version to force loading the new 'branch' field. The modification to the serialization in this change is forward compatible: an old version of the server code can deal with (deserialize) entities written with the new 'branch' field, since this field is optional. Release-Notes: Add 'branch' as a new field in RevisionInfo Forward-Compatible: checked Google-Bug-Id: b/282076066 Change-Id: I166e86d0e52dbaa9b9c3757d2034827653f745fb
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.