c7a061eead
* Update plugins/replication from branch 'master'
to d87fe964ed71f002e2bde2478bf2a9099ed627ff
- Merge branch 'stable-3.1'
* stable-3.1:
PushOne: Improve format of log of references to be pushed
Don't lose state when there's a pending push to the same ref
Change-Id: Ifd3eaa962ea0a3ec81f827e244bed2c303cd1419
- Merge branch 'stable-3.0' into stable-3.1
* stable-3.0:
PushOne: Improve format of log of references to be pushed
Don't lose state when there's a pending push to the same ref
Change-Id: I7d5ecbedad8f061c0f6d44b38ba18322bea19c78
- Merge branch 'stable-2.16' into stable-3.0
* stable-2.16:
PushOne: Improve format of log of references to be pushed
Don't lose state when there's a pending push to the same ref
Change-Id: I78a3f0ff2e596a88d162fbe84caa1282ca1589f6
- PushOne: Improve format of log of references to be pushed
The references to be pushed are logged by just passing the list
of RemoteRefUpdate instances to the logger. This results in the
List's default implementation of toString() being called, which
renders each object in a comma-separated list.
Each object is rendered by RemoteRefUpdate's toString() method
which includes some fields that are not relevant here, or omits
some information that might be useful. For example:
[RemoteRefUpdate[remoteName=refs/meta/config, NOT_ATTEMPTED,
(null)...a7038eb8827cfd29cb3fca335e882f4d5ed09b62, srcRef=refs/meta/config,
forceUpdate, message=null]
- The 'remoteName' is the name on the destination. In this case it's
the same as 'srcRef' but could be different if replication has been
configured to push to a different refname. It is potentially confusing
to have them not logged next to each other.
- '(null)...a7038eb8827cfd29cb3fca335e882f4d5ed09b62' shows the old
and new IDs; this is in the standard git ref update format aside
from '(null)' which is shown instead of zeros.
- 'forceUpdate' is only included when true; this is the same for
the 'fastForward' field.
- the update has a flag indicating if it's a delete, but this is
not included in the output at all.
- 'message' is always null for udates by replication so it's not
necessary to include in the log.
Add a custom method to format the refs for logging, with the information
presented in a clearer way. Continue to log it on a single line, comma-
separated. This might not be ideal for human readers, but makes it easier
when processing the logs with grep or any other tool.
With this change, the logged information looks like:
RemoteRefUpdate{refSpec=refs/meta/config:refs/meta/config,
status=NOT_ATTEMPTED, id=(null)..a7038eb8827cfd29cb3fca335e882f4d5ed09b62
force=yes, delete=no, ffwd=no}
Now the irrelevant information (message) is removed, missing information
(delete) is added, and the source and destination refs are presented in
a single "refSpec" field.
Change-Id: Idd153daf44cd79a0920ea0b72c64ea58d0926f59
- Don't lose state when there's a pending push to the same ref
Previously if there was already a pending push (not an in-flight push)
to the same endpoint, the start for the push would be dropped when
adding the push to the Destination. This meant that a replication start
--wait command would never complete when one of its pushes was pending
since its state would never receive the completion notification for that
push.
Fix this by always adding the state and the ref in the Destination class
and preventing the duplicate "addRef" log message in the PushOne class.
Bug: Issue 12731
Change-Id: I33e6af2709bc38aac791a2f60fd896492167bbf5
Gerrit Code Review
Gerrit is a code review and project management tool for Git based projects.
Objective
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.
Documentation
For information about how to install and use Gerrit, refer to the documentation.
Source
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Reporting bugs
Please report bugs on the issue tracker.
Contribute
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.
Getting in contact
The Developer Mailing list is repo-discuss on Google Groups.
License
Gerrit is provided under the Apache License 2.0.
Build
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit
cd gerrit && bazel build release
Install binary packages (Deb/Rpm)
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>]
Use pre-built Gerrit images on Docker
Docker images of Gerrit are available on DockerHub
To run a CentOS 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.