![]() Submit type rules allow different changes to the same branch to have different submit types. A main use case for this functionality is allowing branch-specific rather than project-specific submit types. However, in theory this also allows a single batch of commits to mix submit types. MergeOp currently handles this situation by splitting up open changes on a branch by submit type and running submit types on each subset in arbitrary order (based on HashMap iteration). My thesis is that this behavior produces nondeterministic results that, even if we can justify them as "sane", are likely to be surprising and/or confusing to the user, and that we are better off failing fast rather than trying to support this scenario. In the past, there was a distinct reason for this behavior, which was that there might be (through no fault of a user) changes in the submitted state with various submit types. Spinning through the submit type list and making progress, while perhaps confusing, was probably better than not making progress at all. But now that the submitted state is gone, the only way in which multiple changes can be submitted at once is within a single batch (including parents or by topic), so this reasoning does not really exist any more. For one example of confusing behavior, say we have two changes A<-B based on the branch tip 0, where A is Merge Always and B is Merge If Necessary. If MergeOp chooses to run Merge Always first, the resulting history will be: 0----Ma--Mab \-A-/ / \-B-/ If, however, MergeOp chooses to run Merge If Necessary first, the merge sorter will choose the fast-forward resolution for B, resulting in: 0--A--B When Merge Always runs, it will find that A is already merged and do nothing. For another example, consider three changes A<-B<-C, where A and C are Cherry-Pick and B is Merge If Necessary. If MergeOp chooses to run Cherry-Pick first, it cherry-picks A' and C': 0--A'--C' Then merging B fails since it now depends on an out-of-date patch set of A. If MergeOp chooses Merge If Necessary first, then B gets chosen as a fast-forward and C gets cherry-picked on top: 0--A--B--C' It is not at all obvious that any one of these solutions is what the user expects to get, to say nothing of more complicated cases. Note that I am only about 75% sure of what actually happens in these scenarios; I might be completely wrong. That just goes to show how weird this behavior is. Enforce during validateChangeList that only a single submit type is present on each branch. This also eliminates one level of looping in the main integrateIntoHistory logic. Another possible solution would be in the case of mixed submit types to run the entire process one change at a time in topological order. This at least might be easier to reason about, although it would still not always succeed, for example if a Merge Always change follows a Cherry-Pick change. But it would introduce considerably more complexity to rework the loops in MergeOp, all for the questionable benefit of making it easier for users to get into a confused situation. Better to just not let them do it at all. Change-Id: I0cec2a7e3e3625fedbdd621b0c6eca6c4100f232 |
||
---|---|---|
.settings | ||
bucklets | ||
contrib | ||
Documentation | ||
gerrit-acceptance-framework | ||
gerrit-acceptance-tests | ||
gerrit-antlr | ||
gerrit-cache-h2 | ||
gerrit-common | ||
gerrit-extension-api | ||
gerrit-gpg | ||
gerrit-gwtdebug | ||
gerrit-gwtexpui | ||
gerrit-gwtui | ||
gerrit-gwtui-common | ||
gerrit-httpd | ||
gerrit-launcher | ||
gerrit-lucene | ||
gerrit-main | ||
gerrit-oauth | ||
gerrit-openid | ||
gerrit-patch-commonsnet | ||
gerrit-patch-jgit | ||
gerrit-pgm | ||
gerrit-plugin-api | ||
gerrit-plugin-archetype | ||
gerrit-plugin-gwt-archetype | ||
gerrit-plugin-gwtui | ||
gerrit-plugin-js-archetype | ||
gerrit-prettify | ||
gerrit-reviewdb | ||
gerrit-server | ||
gerrit-sshd | ||
gerrit-util-cli | ||
gerrit-util-http | ||
gerrit-util-ssl | ||
gerrit-war | ||
lib | ||
plugins | ||
polygerrit-ui | ||
ReleaseNotes | ||
tools | ||
website/releases | ||
.buckconfig | ||
.buckversion | ||
.editorconfig | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
.pydevproject | ||
.watchmanconfig | ||
BUCK | ||
COPYING | ||
INSTALL | ||
README.md | ||
SUBMITTING_PATCHES | ||
VERSION |
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 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>]
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).