7063a4b8f0
Recently the MergeQueue was removed, such that the submit process will directly tell users the result of their submission (merge or reject). For that changes were submitted and directly merged after. If problems (such as a server going down, power loss etc.) occur between setting the submitted state and the actual merge being performed, these changes would be stuck in the submitted state, which is annoying UI wise, but the user could just try to resubmit once the problems are solved. This change moves changes directly from NEW to MERGED if possible or rejects otherwise. We still need to keep lots of code in the Submit class to record the Submit label. Eventually this can be moved into the MergeOp as well. The MergeOp doesn't rely on the submitted state as well any more but just integrates the given changes. So changes which are submitted, but not merged on the same branch are left untouched now. So the tests which are testing exactly these corner cases of submitted changes on the same branch are adapted. Currently the test `submitMultipleChanges` is rather testing that the other changes on the same target branch are left alone. Instead we want to test if the submit strategy can submit changes both via fast forward as well as merging if it's necessary. After applying this change the name of `submitMultipleChanges` is correct again. There is no access to the submitter when running a submit strategy as it is not in the submitted state any more, so we need another way of transporting the information of who is trying to integrate the change to the submit strategy, so we do that via another argument in SubmitStrategy$Argument. The CherryPick strategy has a slight change in behavior as well. The committer for a cherry-picked change will be the server instead of the submitter as this aligns better with the other submit strategies, creating new commits on behalf of the user. Change-Id: I9a0c111c1cb3544774b2783c4f76318e2634faf2
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 IRC channel on freenode is #gerrit. An archive is available at: echelog.com.
The Developer Mailing list is repo-discuss on Google Groups.
License
Gerrit is provided under the Apache License 2.0.
Build
Install Buck and run the following:
git clone --recursive https://gerrit.googlesource.com/gerrit
cd gerrit && buck build all
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>]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.
Events
- November 7-8 2015: Gerrit User Conference, Mountain View. (Register).
- November 9-13 2015: Gerrit Hackathon, Mountain View. (Invitation Only).
- March 2016: Gerrit Hackathon, Berlin. (Details to be confirmed).