Retire repo
Change-Id: I7d68f82c75cbc4dc7e843198593846e19cf88f14
This commit is contained in:
Ian Wienand
parent
ac5628a6ff
commit
234ed85a92
|
|
@ -1,5 +0,0 @@
|
|||
/.classpath
|
||||
/.project
|
||||
/.settings/org.eclipse.jdt.core.prefs
|
||||
/.settings/org.maven.ide.eclipse.prefs
|
||||
/test_site
|
||||
202
COPYING
202
COPYING
|
|
@ -1,202 +0,0 @@
|
|||
|
||||
Apache License
|
||||
Version 2.0, January 2004
|
||||
http://www.apache.org/licenses/
|
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
||||
|
||||
1. Definitions.
|
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction,
|
||||
and distribution as defined by Sections 1 through 9 of this document.
|
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by
|
||||
the copyright owner that is granting the License.
|
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all
|
||||
other entities that control, are controlled by, or are under common
|
||||
control with that entity. For the purposes of this definition,
|
||||
"control" means (i) the power, direct or indirect, to cause the
|
||||
direction or management of such entity, whether by contract or
|
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
||||
outstanding shares, or (iii) beneficial ownership of such entity.
|
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity
|
||||
exercising permissions granted by this License.
|
||||
|
||||
"Source" form shall mean the preferred form for making modifications,
|
||||
including but not limited to software source code, documentation
|
||||
source, and configuration files.
|
||||
|
||||
"Object" form shall mean any form resulting from mechanical
|
||||
transformation or translation of a Source form, including but
|
||||
not limited to compiled object code, generated documentation,
|
||||
and conversions to other media types.
|
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or
|
||||
Object form, made available under the License, as indicated by a
|
||||
copyright notice that is included in or attached to the work
|
||||
(an example is provided in the Appendix below).
|
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object
|
||||
form, that is based on (or derived from) the Work and for which the
|
||||
editorial revisions, annotations, elaborations, or other modifications
|
||||
represent, as a whole, an original work of authorship. For the purposes
|
||||
of this License, Derivative Works shall not include works that remain
|
||||
separable from, or merely link (or bind by name) to the interfaces of,
|
||||
the Work and Derivative Works thereof.
|
||||
|
||||
"Contribution" shall mean any work of authorship, including
|
||||
the original version of the Work and any modifications or additions
|
||||
to that Work or Derivative Works thereof, that is intentionally
|
||||
submitted to Licensor for inclusion in the Work by the copyright owner
|
||||
or by an individual or Legal Entity authorized to submit on behalf of
|
||||
the copyright owner. For the purposes of this definition, "submitted"
|
||||
means any form of electronic, verbal, or written communication sent
|
||||
to the Licensor or its representatives, including but not limited to
|
||||
communication on electronic mailing lists, source code control systems,
|
||||
and issue tracking systems that are managed by, or on behalf of, the
|
||||
Licensor for the purpose of discussing and improving the Work, but
|
||||
excluding communication that is conspicuously marked or otherwise
|
||||
designated in writing by the copyright owner as "Not a Contribution."
|
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity
|
||||
on behalf of whom a Contribution has been received by Licensor and
|
||||
subsequently incorporated within the Work.
|
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the
|
||||
Work and such Derivative Works in Source or Object form.
|
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of
|
||||
this License, each Contributor hereby grants to You a perpetual,
|
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
||||
(except as stated in this section) patent license to make, have made,
|
||||
use, offer to sell, sell, import, and otherwise transfer the Work,
|
||||
where such license applies only to those patent claims licensable
|
||||
by such Contributor that are necessarily infringed by their
|
||||
Contribution(s) alone or by combination of their Contribution(s)
|
||||
with the Work to which such Contribution(s) was submitted. If You
|
||||
institute patent litigation against any entity (including a
|
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
||||
or a Contribution incorporated within the Work constitutes direct
|
||||
or contributory patent infringement, then any patent licenses
|
||||
granted to You under this License for that Work shall terminate
|
||||
as of the date such litigation is filed.
|
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the
|
||||
Work or Derivative Works thereof in any medium, with or without
|
||||
modifications, and in Source or Object form, provided that You
|
||||
meet the following conditions:
|
||||
|
||||
(a) You must give any other recipients of the Work or
|
||||
Derivative Works a copy of this License; and
|
||||
|
||||
(b) You must cause any modified files to carry prominent notices
|
||||
stating that You changed the files; and
|
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works
|
||||
that You distribute, all copyright, patent, trademark, and
|
||||
attribution notices from the Source form of the Work,
|
||||
excluding those notices that do not pertain to any part of
|
||||
the Derivative Works; and
|
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its
|
||||
distribution, then any Derivative Works that You distribute must
|
||||
include a readable copy of the attribution notices contained
|
||||
within such NOTICE file, excluding those notices that do not
|
||||
pertain to any part of the Derivative Works, in at least one
|
||||
of the following places: within a NOTICE text file distributed
|
||||
as part of the Derivative Works; within the Source form or
|
||||
documentation, if provided along with the Derivative Works; or,
|
||||
within a display generated by the Derivative Works, if and
|
||||
wherever such third-party notices normally appear. The contents
|
||||
of the NOTICE file are for informational purposes only and
|
||||
do not modify the License. You may add Your own attribution
|
||||
notices within Derivative Works that You distribute, alongside
|
||||
or as an addendum to the NOTICE text from the Work, provided
|
||||
that such additional attribution notices cannot be construed
|
||||
as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and
|
||||
may provide additional or different license terms and conditions
|
||||
for use, reproduction, or distribution of Your modifications, or
|
||||
for any such Derivative Works as a whole, provided Your use,
|
||||
reproduction, and distribution of the Work otherwise complies with
|
||||
the conditions stated in this License.
|
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise,
|
||||
any Contribution intentionally submitted for inclusion in the Work
|
||||
by You to the Licensor shall be under the terms and conditions of
|
||||
this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify
|
||||
the terms of any separate license agreement you may have executed
|
||||
with Licensor regarding such Contributions.
|
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade
|
||||
names, trademarks, service marks, or product names of the Licensor,
|
||||
except as required for reasonable and customary use in describing the
|
||||
origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or
|
||||
agreed to in writing, Licensor provides the Work (and each
|
||||
Contributor provides its Contributions) on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
implied, including, without limitation, any warranties or conditions
|
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
||||
PARTICULAR PURPOSE. You are solely responsible for determining the
|
||||
appropriateness of using or redistributing the Work and assume any
|
||||
risks associated with Your exercise of permissions under this License.
|
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory,
|
||||
whether in tort (including negligence), contract, or otherwise,
|
||||
unless required by applicable law (such as deliberate and grossly
|
||||
negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special,
|
||||
incidental, or consequential damages of any character arising as a
|
||||
result of this License or out of the use or inability to use the
|
||||
Work (including but not limited to damages for loss of goodwill,
|
||||
work stoppage, computer failure or malfunction, or any and all
|
||||
other commercial damages or losses), even if such Contributor
|
||||
has been advised of the possibility of such damages.
|
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing
|
||||
the Work or Derivative Works thereof, You may choose to offer,
|
||||
and charge a fee for, acceptance of support, warranty, indemnity,
|
||||
or other liability obligations and/or rights consistent with this
|
||||
License. However, in accepting such obligations, You may act only
|
||||
on Your own behalf and on Your sole responsibility, not on behalf
|
||||
of any other Contributor, and only if You agree to indemnify,
|
||||
defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason
|
||||
of your accepting any such warranty or additional liability.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "[]"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
*.html
|
||||
/.published
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
V=$(git describe HEAD)
|
||||
|
||||
case "$V" in
|
||||
'')
|
||||
echo >&2 "fatal: no annotated tags, cannot determine version"
|
||||
exit 1
|
||||
;;
|
||||
|
||||
*-g*)
|
||||
echo >&2 "fatal: snapshot $V, cannot determine version"
|
||||
exit 1
|
||||
;;
|
||||
|
||||
v*)
|
||||
echo "$V" | perl -lne 'print $1 if /^v(\d+\.\d+(?:\.\d+)?)/'
|
||||
;;
|
||||
esac
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
# Copyright (C) 2009 The Android Open Source Project
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
ASCIIDOC ?= asciidoc
|
||||
ASCIIDOC_EXTRA ?=
|
||||
SVN ?= svn
|
||||
PUB_ROOT ?= https://gerrit.googlecode.com/svn/documentation
|
||||
|
||||
all: html
|
||||
|
||||
clean:
|
||||
rm -f *.html
|
||||
rm -rf $(LOCAL_ROOT)
|
||||
|
||||
ifeq ($(origin VERSION), undefined)
|
||||
VERSION := $(shell ./GEN-DOC-VERSION 2>/dev/null)
|
||||
endif
|
||||
|
||||
DOC_HTML := $(patsubst %.txt,%.html,$(wildcard *.txt))
|
||||
LOCAL_ROOT := .published
|
||||
COMMIT := $(shell git describe HEAD | sed s/^v//)
|
||||
PUB_DIR := $(PUB_ROOT)/$(VERSION)
|
||||
PRIOR = PRIOR
|
||||
|
||||
ifeq ($(VERSION),)
|
||||
REVISION = $(COMMIT)
|
||||
else
|
||||
ifeq ($(VERSION),$(COMMIT))
|
||||
REVISION := $(VERSION)
|
||||
else
|
||||
REVISION := $(VERSION) (from v$(COMMIT))
|
||||
endif
|
||||
endif
|
||||
|
||||
html: $(DOC_HTML)
|
||||
|
||||
update: html
|
||||
ifeq ($(VERSION),)
|
||||
./GEN-DOC-VERSION
|
||||
endif
|
||||
@-rm -rf $(LOCAL_ROOT)
|
||||
@echo "Checking out current $(VERSION)"
|
||||
@if ! $(SVN) checkout $(PUB_DIR) $(LOCAL_ROOT) 2>/dev/null ; then \
|
||||
echo "Copying $(PRIOR) to $(VERSION) ..." && \
|
||||
$(SVN) cp -m "Create $(VERSION) documentation" $(PUB_ROOT)/$(PRIOR) $(PUB_DIR) && \
|
||||
$(SVN) checkout $(PUB_DIR) $(LOCAL_ROOT) ; \
|
||||
fi
|
||||
@rm -f $(LOCAL_ROOT)/*.html
|
||||
@cp *.html $(LOCAL_ROOT)
|
||||
@cd $(LOCAL_ROOT) && \
|
||||
r=`$(SVN) status | perl -ne 'print if s/^! *//' ` && \
|
||||
if [ -n "$$r" ]; then $(SVN) rm $$r; fi && \
|
||||
a=`$(SVN) status | perl -ne 'print if s/^\? *//' ` && \
|
||||
if [ -n "$$a" ]; then \
|
||||
$(SVN) add $$a && \
|
||||
$(SVN) propset svn:mime-type text/html $$a ; \
|
||||
fi && \
|
||||
echo "Committing $(VERSION) at v$(COMMIT)" && \
|
||||
$(SVN) commit -m "Updated $(VERSION) documentation to v$(COMMIT)"
|
||||
@-rm -rf $(LOCAL_ROOT)
|
||||
|
||||
$(DOC_HTML): %.html : %.txt
|
||||
@echo "FORMAT $@"
|
||||
@rm -f $@+ $@
|
||||
@$(ASCIIDOC) -a toc \
|
||||
-a 'revision=$(REVISION)' \
|
||||
-b xhtml11 \
|
||||
-f asciidoc.conf \
|
||||
$(ASCIIDOC_EXTRA) \
|
||||
-o $@+ $<
|
||||
@mv $@+ $@
|
||||
|
|
@ -1,701 +0,0 @@
|
|||
Gerrit Code Review - Access Controls
|
||||
====================================
|
||||
|
||||
Access controls in Gerrit are group based. Every user account is a
|
||||
member of one or more groups, and access and privileges are granted
|
||||
to those groups. Access rights cannot be granted to individual
|
||||
users.
|
||||
|
||||
|
||||
System Groups
|
||||
-------------
|
||||
|
||||
Gerrit comes with 4 system groups, with special access privileges
|
||||
and membership management. The identity of these groups is set
|
||||
in the `system_config` table within the database, so the groups
|
||||
can be renamed after installation if desired.
|
||||
|
||||
[[administrators]]
|
||||
Administrators
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
This is the Gerrit "root" identity.
|
||||
|
||||
Users in the 'Administrators' group can perform any action under
|
||||
the Admin menu, to any group or project, without further validation
|
||||
of any other access controls. In most installations only those
|
||||
users who have direct filesystem and database access would be
|
||||
placed into this group.
|
||||
|
||||
Membership in the 'Administrators' group does not imply any other
|
||||
access rights. Administrators do not automatically get code review
|
||||
approval or submit rights in projects. This is a feature designed
|
||||
to permit administrative users to otherwise access Gerrit as any
|
||||
other normal user would, without needing two different accounts.
|
||||
|
||||
Anonymous Users
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
All users are automatically a member of this group. Users who are
|
||||
not signed in are a member of only this group, and no others.
|
||||
|
||||
Any access rights assigned to this group are inherited by all users.
|
||||
|
||||
Administrators and project owners can grant access rights to this
|
||||
group in order to permit anonymous users to view project changes,
|
||||
without requiring sign in first. Currently it is only worthwhile
|
||||
to grant `Read Access` to this group as Gerrit requires an account
|
||||
identity for all other operations.
|
||||
|
||||
Registered Users
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
All signed-in users are automatically a member of this group (and
|
||||
also 'Anonymous Users', see above).
|
||||
|
||||
Any access rights assigned to this group are inherited by all
|
||||
users as soon as they sign-in to Gerrit. If OpenID authentication
|
||||
is being employed, moving from only 'Anonymous Users' into this
|
||||
group is very easy. Caution should be taken when assigning any
|
||||
permissions to this group.
|
||||
|
||||
It is typical to assign `Code Review -1..+1` to this group,
|
||||
allowing signed-in users to vote on a change, but not actually
|
||||
cause it to become approved or rejected.
|
||||
|
||||
Registered users are always permitted to make and publish comments
|
||||
on any change in any project they have `Read Access` to.
|
||||
|
||||
Project Owners
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Access rights assigned to this group are always evaluated within the
|
||||
context of a project and are resolved to access rights for all users
|
||||
which own the project.
|
||||
|
||||
By assigning access rights to this group on a parent project Gerrit
|
||||
administrators can define a set of default access rights for project
|
||||
owners. Child projects inherit these access rights where they are
|
||||
resolved to the users that own the child project.
|
||||
Having default access rights for projects owners assigned on a parent
|
||||
project may avoid the need to initially configure access rights for
|
||||
newly created child projects.
|
||||
|
||||
|
||||
Account Groups
|
||||
--------------
|
||||
|
||||
Account groups contain a list of zero or more user account members,
|
||||
added individually by a group owner. Any user account listed as
|
||||
a group member is given any access rights granted to the group.
|
||||
|
||||
Every group has one other group designated as its owner. Users who
|
||||
are members of the owner group can:
|
||||
|
||||
* Add users to this group
|
||||
* Remove users from this group
|
||||
* Change the name of this group
|
||||
* Change the description of this group
|
||||
* Change the owner of this group, to another group
|
||||
|
||||
It is permissible for a group to own itself, allowing the group
|
||||
members to directly manage who their peers are.
|
||||
|
||||
Newly created groups are automatically created as owning themselves,
|
||||
with the creating user as the only member. This permits the group
|
||||
creator to add additional members, and change the owner to another
|
||||
group if desired.
|
||||
|
||||
It is somewhat common to create two groups at the same time,
|
||||
for example `Foo` and `Foo-admin`, where the latter group
|
||||
`Foo-admin` owns both itself and also group `Foo`. Users who
|
||||
are members of `Foo-admin` can thus control the membership of
|
||||
`Foo`, without actually having the access rights granted to `Foo`.
|
||||
This configuration can help prevent accidental submits when the
|
||||
members of `Foo` have submit rights on a project, and the members of
|
||||
`Foo-admin` typically do not need to have such rights.
|
||||
|
||||
|
||||
Project Access Control Lists
|
||||
----------------------------
|
||||
|
||||
A system wide access control list affecting all projects is stored in
|
||||
project "`\-- All Projects \--`". This inheritance can be configured
|
||||
through link:cmd-set-project-parent.html[gerrit set-project-parent].
|
||||
|
||||
Per-project access control lists are also supported.
|
||||
|
||||
Users are permitted to use the maximum range granted to any of their
|
||||
groups in an approval category. For example, a user is a member of
|
||||
`Foo Leads`, and the following ACLs are granted on a project:
|
||||
|
||||
[options="header"]
|
||||
|=================================================
|
||||
|Group |Reference Name |Category|Range
|
||||
|Anonymous Users |refs/heads/*|Code Review|-1..+1
|
||||
|Registered Users|refs/heads/*|Code Review|-1..+2
|
||||
|Foo Leads |refs/heads/*|Code Review|-2..0
|
||||
|=================================================
|
||||
|
||||
Then the effective range permitted to be used by the user is
|
||||
`-2..+2`, as the user is a member of all three groups (see above
|
||||
about the system groups) and the maximum range is chosen (so the
|
||||
lowest value granted to any group, and the highest value granted
|
||||
to any group).
|
||||
|
||||
Reference-level access control is also possible.
|
||||
|
||||
Permissions can be set on a single reference name to match one
|
||||
branch (e.g. `refs/heads/master`), or on a reference namespace
|
||||
(e.g. `refs/heads/\*`) to match any branch starting with that
|
||||
prefix. So a permission with `refs/heads/\*` will match
|
||||
`refs/heads/master` and `refs/heads/experimental`, etc.
|
||||
|
||||
Reference names can also be described with a regular expression
|
||||
by prefixing the reference name with `\^`. For example
|
||||
`\^refs/heads/[a-z]\{1,8\}` matches all lower case branch names
|
||||
between 1 and 8 characters long. Within a regular expression `.`
|
||||
is a wildcard matching any character, but may be escaped as `\.`.
|
||||
The link:http://www.brics.dk/automaton/[dk.brics.automaton library]
|
||||
is used for evaluation of regular expression access control
|
||||
rules. See the library documentation for details on this
|
||||
particular regular expression flavor.
|
||||
|
||||
References can have the current user name automatically included,
|
||||
creating dynamic access controls that change to match the currently
|
||||
logged in user. For example to provide a personal sandbox space
|
||||
to all developers, `refs/heads/sandbox/$\{username\}/*` allowing
|
||||
the user 'joe' to use 'refs/heads/sandbox/joe/foo'.
|
||||
|
||||
When evaluating a reference-level access right, Gerrit will use
|
||||
the full set of access rights to determine if the user
|
||||
is allowed to perform a given action. For example, if a user is a
|
||||
member of `Foo Leads`, they are reviewing a change destined for
|
||||
the `refs/heads/qa` branch, and the following ACLs are granted
|
||||
on the project:
|
||||
|
||||
[options="header"]
|
||||
|=====================================================
|
||||
|Group |Reference Name|Category |Range
|
||||
|Registered Users |refs/heads/* |Code Review| -1..+1
|
||||
|Foo Leads |refs/heads/* |Code Review| -2..+2
|
||||
|QA Leads |refs/heads/qa |Code Review| -2..+2
|
||||
|=====================================================
|
||||
|
||||
Then the effective range permitted to be used by the user is
|
||||
`-2..+2`, as the user's membership of `Foo Leads` effectively grant
|
||||
them access to the entire reference space, thanks to the wildcard.
|
||||
|
||||
Gerrit also supports exclusive reference-level access control.
|
||||
|
||||
It is possible to configure Gerrit to grant an exclusive ref level
|
||||
access control so that only users of a specific group can perform
|
||||
an operation on a project/reference pair. This is done by prefixing
|
||||
the reference specified with a `'-'`.
|
||||
|
||||
For example, if a user who is a member of `Foo Leads` tries to
|
||||
review a change destined for branch `refs/heads/qa` in a project,
|
||||
and the following ACLs are granted:
|
||||
|
||||
[options="header"]
|
||||
|=====================================================
|
||||
|Group |Reference Name|Category |Range
|
||||
|Registered Users|refs/heads/* |Code Review| -1..+1
|
||||
|Foo Leads |refs/heads/* |Code Review| -2..+2
|
||||
|QA Leads |-refs/heads/qa|Code Review| -2..+2
|
||||
|=====================================================
|
||||
|
||||
Then this user will not have `Code Review` rights on that change,
|
||||
since there is an exclusive access right in place for the
|
||||
`refs/heads/qa` branch. This allows locking down access for a
|
||||
particular branch to a limited set of users, bypassing inherited
|
||||
rights and wildcards.
|
||||
|
||||
In order to grant the ability to `Code Review` to the members of
|
||||
`Foo Leads`, in `refs/heads/qa` then the following access rights
|
||||
would be needed:
|
||||
|
||||
[options="header"]
|
||||
|=====================================================
|
||||
|Group |Reference Name|Category |Range
|
||||
|Registered Users|refs/heads/* |Code Review| -1..+1
|
||||
|Foo Leads |refs/heads/* |Code Review| -2..+2
|
||||
|QA Leads |-refs/heads/qa|Code Review| -2..+2
|
||||
|Foo Leads |refs/heads/qa |Code Review| -2..+2
|
||||
|=====================================================
|
||||
|
||||
|
||||
OpenID Authentication
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If the Gerrit instance is configured to use OpenID authentication,
|
||||
an account's effective group membership will be restricted to only
|
||||
the `Anonymous Users` and `Registered Users` groups, unless *all*
|
||||
of its OpenID identities match one or more of the patterns listed
|
||||
in the `auth.trustedOpenID` list from `gerrit.config`.
|
||||
|
||||
All Projects
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Any access right granted to a group within `\-- All Projects \--`
|
||||
is automatically inherited by every other project in the same
|
||||
Gerrit instance. These rights can be seen, but not modified,
|
||||
in any other project's `Access` administration tab.
|
||||
|
||||
Only members of the group `Administrators` may edit the access
|
||||
control list for `\-- All Projects \--`.
|
||||
|
||||
Ownership of this project cannot be delegated to another group.
|
||||
This restriction is by design. Granting ownership to another
|
||||
group gives nearly the same level of access as membership in
|
||||
`Administrators` does, as group members would be able to alter
|
||||
permissions for every managed project.
|
||||
|
||||
Per-Project
|
||||
~~~~~~~~~~~
|
||||
|
||||
The per-project ACL is evaluated before the global
|
||||
`\-- All Projects \--` ACL, permitting some limited override
|
||||
capability to project owners. This behavior is generally only
|
||||
useful on the `Read Access` category when granting `-1 No Access`
|
||||
within a specific project to deny access to a group.
|
||||
|
||||
|
||||
Categories
|
||||
----------
|
||||
|
||||
Gerrit comes pre-configured with several default categories that
|
||||
can be granted to groups within projects, enabling functionality
|
||||
for that group's members.
|
||||
|
||||
[[category_OWN]]
|
||||
Owner
|
||||
~~~~~
|
||||
|
||||
The `Owner` category controls which groups can modify the project's
|
||||
configuration. Users who are members of an owner group can:
|
||||
|
||||
* Change the project description
|
||||
* Create/delete a branch through the web UI (not SSH)
|
||||
* Grant/revoke any access rights, including `Owner`
|
||||
|
||||
Note that project owners implicitly have branch creation or deletion
|
||||
through the web UI, but not through SSH. To get SSH branch access
|
||||
project owners must grant an access right to a group they are a
|
||||
member of, just like for any other user.
|
||||
|
||||
Ownership over a particular branch subspace may be delegated by
|
||||
entering a branch pattern. To delegate control over all branches
|
||||
that begin with `qa/` to the QA group, add `Owner` category
|
||||
for reference `refs/heads/qa/\*`. Members of the QA group can
|
||||
further refine access, but only for references that begin with
|
||||
`refs/heads/qa/`.
|
||||
|
||||
[[category_READ]]
|
||||
Read Access
|
||||
~~~~~~~~~~~
|
||||
|
||||
The `Read Access` category controls visibility to the project's
|
||||
changes, comments, code diffs, and Git access over SSH or HTTP.
|
||||
A user must have `Read Access +1` in order to see a project, its
|
||||
changes, or any of its data.
|
||||
|
||||
This category has a special behavior, where the per-project ACL is
|
||||
evaluated before the global all projects ACL. If the per-project
|
||||
ACL has granted `Read Access -1`, and does not otherwise grant
|
||||
`Read Access \+1`, then a `Read Access +1` in the all projects ACL
|
||||
is ignored. This behavior is useful to hide a handful of projects
|
||||
on an otherwise public server.
|
||||
|
||||
For an open source, public Gerrit installation it is common to grant
|
||||
`Read Access +1` to `Anonymous Users` in the `\-- All Projects
|
||||
\--` ACL, enabling casual browsing of any project's changes,
|
||||
as well as fetching any project's repository over SSH or HTTP.
|
||||
New projects can be temporarily hidden from public view by granting
|
||||
`Read Access -1` to `Anonymous Users` and granting `Read Access +1`
|
||||
to the project owner's group within the per-project ACL.
|
||||
|
||||
For a private Gerrit installation using a trusted HTTP authentication
|
||||
source, granting `Read Access +1` to `Registered Users` may be more
|
||||
typical, enabling read access only to those users who have been
|
||||
able to authenticate through the HTTP access controls. This may
|
||||
be suitable in a corporate deployment if the HTTP access control
|
||||
is already restricted to the correct set of users.
|
||||
|
||||
[[category_READ_2]]
|
||||
Upload Access
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The `Read Access +2` permits the user to upload a non-merge commit
|
||||
to the project's `refs/for/BRANCH` namespace, creating a new change
|
||||
for code review.
|
||||
|
||||
Rather than place this permission in its own category, its chained
|
||||
into the Read Access category as a higher level of access. A user
|
||||
must be able to clone or fetch the project in order to create a new
|
||||
commit on their local system, so in practice they must also have
|
||||
Read Access +1 to even develop a change. Therefore upload access
|
||||
implies read access by simply being a higher level of it.
|
||||
|
||||
For an open source, public Gerrit installation, it is common to
|
||||
grant `Read Access +1..+2` to `Registered Users` in the `\-- All
|
||||
Projects \--` ACL. For more private installations, its common to
|
||||
simply grant `Read Access +1..+2` to all users of a project.
|
||||
|
||||
[[category_READ_3]]
|
||||
Upload Merge Access
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
The `Read Access +3` permits the user to upload merge commits, but is
|
||||
otherwise identical to `Read Access +2`. Some projects wish to
|
||||
restrict merges to being created by Gerrit. By granting,
|
||||
`Read Access +1..+2`, the only merges that enter the system will be
|
||||
those created by Gerrit, or those pushed directly.
|
||||
|
||||
[[category_pTAG]]
|
||||
Push Tag
|
||||
~~~~~~~~
|
||||
|
||||
This category permits users to push an annotated tag object over
|
||||
SSH into the project's repository. Typically this would be done
|
||||
with a command line such as:
|
||||
|
||||
====
|
||||
git push ssh://USER@HOST:PORT/PROJECT tag v1.0
|
||||
====
|
||||
|
||||
Tags must be annotated (created with `git tag -a` or `git tag -s`),
|
||||
should exist in the `refs/tags/` namespace, and should be new.
|
||||
|
||||
This category is intended to be used to publish tags when a project
|
||||
reaches a stable release point worth remembering in history.
|
||||
|
||||
The range of values is:
|
||||
|
||||
* +1 Create Signed Tag
|
||||
+
|
||||
A new signed tag may be created. The tagger email address must be
|
||||
verified for the current user.
|
||||
|
||||
* +2 Create Annotated Tag
|
||||
+
|
||||
A new annotated (unsigned) tag may be created. The tagger email
|
||||
address must be verified for the current user.
|
||||
|
||||
To push tags created by users other than the current user (such
|
||||
as tags mirrored from an upstream project), `Forge Identity +2`
|
||||
must be also granted in addition to `Push Tag >= +1`.
|
||||
|
||||
To push lightweight (non annotated) tags, grant `Push Branch +2
|
||||
Create Branch` for reference name `refs/tags/*`, as lightweight
|
||||
tags are implemented just like branches in Git.
|
||||
|
||||
To delete or overwrite an existing tag, grant `Push Branch +3
|
||||
Force Push Branch; Delete Branch` for reference name `refs/tags/*`,
|
||||
as deleting a tag requires the same permission as deleting a branch.
|
||||
|
||||
[[category_pHD]]
|
||||
Push Branch
|
||||
~~~~~~~~~~~
|
||||
|
||||
This category permits users to push directly into a branch over SSH,
|
||||
bypassing any code review process that would otherwise be used.
|
||||
|
||||
This category has several possible values:
|
||||
|
||||
* +1 Update Branch
|
||||
+
|
||||
Any existing branch can be fast-forwarded to a new commit.
|
||||
Creation of new branches is rejected. Deletion of existing branches
|
||||
is rejected. This is the safest mode as commits cannot be discarded.
|
||||
|
||||
* +2 Create Branch
|
||||
+
|
||||
Implies 'Update Branch', but also allows the creation of a new branch
|
||||
if the name does not not already designate an existing branch name.
|
||||
Like update branch, existing commits cannot be discarded.
|
||||
|
||||
* +3 Force Push Branch; Delete Branch
|
||||
+
|
||||
Implies both 'Update Branch' and 'Create Branch', but also allows an
|
||||
existing branch to be deleted. Since a force push is effectively a
|
||||
delete immediately followed by a create, but performed atomically on
|
||||
the server and logged, this level also permits forced push updates
|
||||
to branches. This level may allow existing commits to be discarded
|
||||
from a project history.
|
||||
|
||||
This category is primarily useful for projects that only want to
|
||||
take advantage of Gerrit's access control features and do not need
|
||||
its code review functionality. Projects that need to require code
|
||||
reviews should not grant this category.
|
||||
|
||||
[[category_FORG]]
|
||||
Forge Identity
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Normally Gerrit requires the author and the committer identity
|
||||
lines in a Git commit object (or tagger line in an annotated tag) to
|
||||
match one of the registered email addresses of the uploading user.
|
||||
This permission allows users to bypass that validation, which may
|
||||
be necessary when mirroring changes from an upstream project.
|
||||
|
||||
* +1 Forge Author Identity
|
||||
+
|
||||
Permits the use of an unverified author line in commit objects.
|
||||
This can be useful when applying patches received by email from
|
||||
3rd parties, when cherry-picking changes written by others across
|
||||
branches, or when amending someone else's commit to fix up a minor
|
||||
problem before submitting.
|
||||
+
|
||||
By default this is granted to `Registered Users` in all projects,
|
||||
but a site administrator may disable it if verified authorship
|
||||
is required.
|
||||
|
||||
* +2 Forge Committer or Tagger Identity
|
||||
+
|
||||
Implies 'Forge Author Identity', but also allows the use of an
|
||||
unverified committer line in commit objects, or an unverified tagger
|
||||
line in annotated tag objects. Typically this is only required
|
||||
when mirroring commits from an upstream project repository.
|
||||
|
||||
* +3 Forge Gerrit Code Review Server Identity
|
||||
+
|
||||
Implies 'Forge Committer or Tagger Identity' as well as 'Forge
|
||||
Author Identity', but additionally allows the use of the server's
|
||||
own name and email on the committer line of a new commit object.
|
||||
This should only be necessary when force pushing a commit history
|
||||
which has been rewritten by 'git filter-branch' and that contains
|
||||
merge commits previously created by this Gerrit Code Review server.
|
||||
|
||||
[[category_VRIF]]
|
||||
Verified
|
||||
~~~~~~~~
|
||||
|
||||
The verified category can have any meaning the project desires.
|
||||
It was originally invented by the Android Open Source Project to
|
||||
mean 'compiles, passes basic unit tests'.
|
||||
|
||||
The range of values is:
|
||||
|
||||
* -1 Fails
|
||||
+
|
||||
Tried to compile, but got a compile error, or tried to run tests,
|
||||
but one or more tests did not pass.
|
||||
+
|
||||
*Any -1 blocks submit.*
|
||||
|
||||
* 0 No score
|
||||
+
|
||||
Didn't try to perform the verification tasks.
|
||||
|
||||
* +1 Verified
|
||||
+
|
||||
Compiled (and ran tests) successfully.
|
||||
+
|
||||
*Any +1 enables submit.*
|
||||
|
||||
In order to submit a change, the change must have a `+1 Verified` in
|
||||
this category from at least one authorized user, and no `-1 Fails`
|
||||
from an authorized user. Thus, `-1 Fails` can block a submit,
|
||||
while `+1 Verified` enables a submit.
|
||||
|
||||
If a Gerrit installation does not wish to use this category in any
|
||||
project, it can be deleted from the database:
|
||||
|
||||
====
|
||||
DELETE FROM approval_categories WHERE category_id = 'VRIF';
|
||||
DELETE FROM approval_category_values WHERE category_id = 'VRIF';
|
||||
====
|
||||
|
||||
If a Gerrit installation wants to modify the description text
|
||||
associated with these category values, the text can be updated
|
||||
in the `name` column of the `category_id = \'VRIF'` rows in the
|
||||
`approval_category_values` table.
|
||||
|
||||
Additional values could also be added to this category, to allow it
|
||||
to behave more like `Code Review` (below). Insert -2 and +2 value
|
||||
rows into the `approval_category_values` with `category_id` set to
|
||||
`VRIF` to get the same behavior.
|
||||
|
||||
[NOTE]
|
||||
A restart is required after making database changes.
|
||||
See <<restart_changes,below>>.
|
||||
|
||||
[[category_CVRW]]
|
||||
Code Review
|
||||
~~~~~~~~~~~
|
||||
|
||||
The code review category can have any meaning the project desires.
|
||||
It was originally invented by the Android Open Source Project to
|
||||
mean 'I read the code and it seems reasonably correct'.
|
||||
|
||||
The range of values is:
|
||||
|
||||
* -2 Do not submit
|
||||
+
|
||||
The code is so horribly incorrect/buggy/broken that it must not be
|
||||
submitted to this project, or to this branch.
|
||||
+
|
||||
*Any -2 blocks submit.*
|
||||
|
||||
* -1 I would prefer that you didn't submit this
|
||||
+
|
||||
The code doesn't look right, or could be done differently, but
|
||||
the reviewer is willing to live with it as-is if another reviewer
|
||||
accepts it, perhaps because it is better than what is currently in
|
||||
the project. Often this is also used by contributors who don't like
|
||||
the change, but also aren't responsible for the project long-term
|
||||
and thus don't have final say on change submission.
|
||||
+
|
||||
Does not block submit.
|
||||
|
||||
* 0 No score
|
||||
+
|
||||
Didn't try to perform the code review task, or glanced over it but
|
||||
don't have an informed opinion yet.
|
||||
|
||||
* +1 Looks good to me, but someone else must approve
|
||||
+
|
||||
The code looks right to this reviewer, but the reviewer doesn't
|
||||
have access to the `+2` value for this category. Often this is
|
||||
used by contributors to a project who were able to review the change
|
||||
and like what it is doing, but don't have final approval over what
|
||||
gets submitted.
|
||||
|
||||
* +2 Looks good to me, approved
|
||||
+
|
||||
Basically the same as `+1`, but for those who have final say over
|
||||
how the project will develop.
|
||||
+
|
||||
*Any +2 enables submit.*
|
||||
|
||||
In order to submit a change, the change must have a `+2 Looks good to
|
||||
me, approved` in this category from at least one authorized user,
|
||||
and no `-2 Do not submit` from an authorized user. Thus `-2`
|
||||
can block a submit, while `+2` can enable it.
|
||||
|
||||
If a Gerrit installation does not wish to use this category in any
|
||||
project, it can be deleted from the database:
|
||||
|
||||
====
|
||||
DELETE FROM approval_categories WHERE category_id = 'CRVW';
|
||||
DELETE FROM approval_category_values WHERE category_id = 'CRVW';
|
||||
====
|
||||
|
||||
If a Gerrit installation wants to modify the description text
|
||||
associated with these category values, the text can be updated
|
||||
in the `name` column of the `category_id = \'CRVW'` rows in the
|
||||
`approval_category_values` table.
|
||||
|
||||
Additional values could be inserted into `approval_category_values`
|
||||
to further extend the negative and positive range, but there is
|
||||
likely little value in doing so as this only expands the middle
|
||||
region. This category is a `MaxWithBlock` type, which means that
|
||||
the lowest negative value if present blocks a submit, while the
|
||||
highest positive value is required to enable submit.
|
||||
|
||||
[[function_MaxNoBlock]]
|
||||
There is also a `MaxNoBlock` category which still requires the
|
||||
highest positive value to submit, but the lowest negative value will
|
||||
not block the change, and does not carry over between patch sets.
|
||||
This level is mostly useful for automated code-reviews that may
|
||||
have false-negatives that shouldn't block the change.
|
||||
|
||||
[NOTE]
|
||||
A restart is required after making database changes.
|
||||
See <<restart_changes,below>>.
|
||||
|
||||
[[category_SUBM]]
|
||||
Submit
|
||||
~~~~~~
|
||||
|
||||
This category permits users to push the `Submit Patch Set n` button
|
||||
on the web UI.
|
||||
|
||||
Submitting a change causes it to be merged into the destination
|
||||
branch as soon as possible, making it a permanent part of the
|
||||
project's history.
|
||||
|
||||
In order to submit, all approval categories (such as `Verified` and
|
||||
`Code Review`, above) must enable submit, and also must not block it.
|
||||
See above for details on each category.
|
||||
|
||||
[[category_makeoneup]]
|
||||
Your Category Here
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Gerrit administrators can also make up their own categories.
|
||||
|
||||
See above for descriptions of how `Verified` and `Code Review` work,
|
||||
and insert your own category with `function_name = \'MaxWithBlock'`
|
||||
to get the same behavior over your own range of values, in any
|
||||
category you desire.
|
||||
|
||||
Ensure `category_id` is unique within your `approval_categories`
|
||||
table. The default values `VRIF` and `CVRF` used for the categories
|
||||
described above are simply that, defaults, and have no special
|
||||
meaning to Gerrit. The other standard category_id values like
|
||||
`OWN`, `READ`, `SUBM`, `pTAG` and `pHD` have special meaning and
|
||||
should not be modified or reused.
|
||||
|
||||
The `position` column of `approval_categories` controls which column
|
||||
of the 'Approvals' table the category appears in, providing some
|
||||
layout control to the administrator.
|
||||
|
||||
All `MaxWithBlock` categories must have at least one positive value
|
||||
in the `approval_category_values` table, or else submit will never
|
||||
be enabled.
|
||||
|
||||
To permit blocking submits, ensure a negative value is defined for
|
||||
your new category. If you do not wish to have a blocking submit
|
||||
level for your category, do not define values less than 0.
|
||||
|
||||
Keep in mind that category definitions are currently global to
|
||||
the entire Gerrit instance, and affect all projects hosted on it.
|
||||
Any change to a category definition affects everyone.
|
||||
|
||||
For example, to define a new 3-valued category that behaves exactly
|
||||
like `Verified`, but has different names/labels:
|
||||
|
||||
====
|
||||
INSERT INTO approval_categories
|
||||
(name
|
||||
,position
|
||||
,function_name
|
||||
,category_id)
|
||||
VALUES
|
||||
('Copyright Check'
|
||||
,3
|
||||
'MaxWithBlock'
|
||||
,'copy');
|
||||
|
||||
INSERT INTO approval_category_values
|
||||
(category_id,value,name)
|
||||
VALUES
|
||||
('copy', -1, 'Do not have copyright');
|
||||
|
||||
INSERT INTO approval_category_values
|
||||
(category_id,value,name)
|
||||
VALUES
|
||||
('copy', 0, 'No score');
|
||||
|
||||
INSERT INTO approval_category_values
|
||||
(category_id,value,name)
|
||||
VALUES
|
||||
('copy', 1, 'Copyright clear');
|
||||
====
|
||||
|
||||
The new column will appear at the end of the table (in position 3),
|
||||
and `-1 Do not have copyright` will block submit, while `+1 Copyright
|
||||
clear` is required to enable submit.
|
||||
|
||||
[[restart_changes]]
|
||||
[NOTE]
|
||||
Restart the Gerrit web application and reload all browsers after
|
||||
making any database changes to approval categories. Browsers are
|
||||
sent the list of known categories when they first visit the site,
|
||||
and don't notice changes until the page is closed and opened again,
|
||||
or is reloaded.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
[attributes]
|
||||
asterisk=*
|
||||
plus=+
|
||||
caret=^
|
||||
startsb=[
|
||||
endsb=]
|
||||
tilde=~
|
||||
|
||||
[specialsections]
|
||||
GERRIT=gerrituplink
|
||||
|
||||
[gerrituplink]
|
||||
<hr style="
|
||||
height: 2px;
|
||||
color: silver;
|
||||
margin-top: 1.2em;
|
||||
margin-bottom: 0.5em;
|
||||
">
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
gerrit-cherry-pick
|
||||
==================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit-cherry-pick - Download and cherry pick one or more changes
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'gerrit-cherry-pick' <remote> <changeid>...
|
||||
|
||||
'gerrit-cherry-pick' \--continue | \--skip | \--abort
|
||||
|
||||
'gerrit-cherry-pick' \--close <remote>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Downloads the listed changes specified on the command line and
|
||||
proceeds to cherry-pick them (rewriting commit SHA-1s as it goes)
|
||||
onto the current branch.
|
||||
|
||||
If a merge failure prevents this from being completely automatic,
|
||||
you will be asked to resolve the conflict and restart the command
|
||||
with the `\--continue` option.
|
||||
|
||||
Change ids may be specified as either the change id (e.g. 1234)
|
||||
or as change id slash patch set number (e.g. 1234/8). If the patch
|
||||
set number is not supplied, `/1` is assumed.
|
||||
|
||||
The `\--close` command line option is now deprecated, as closing
|
||||
existing changes post cherry-pick is better handled simply by
|
||||
ensuring link:user-changeid.html[Change-Id lines] are present in
|
||||
each commit message.
|
||||
|
||||
OBTAINING
|
||||
---------
|
||||
To obtain the 'gerrit-cherry-pick' script use scp, curl or wget to
|
||||
copy it to your local system:
|
||||
|
||||
$ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
|
||||
|
||||
$ curl http://review.example.com/tools/bin/gerrit-cherry-pick
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
gerrit create-account
|
||||
=====================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit create-account - Create a new batch/role account.
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit create-account' \
|
||||
[\--group <GROUP>] \
|
||||
[\--full-name <FULLNAME>] \
|
||||
[\--email <EMAIL>] \
|
||||
[\--ssh-key -|<KEY>] \
|
||||
<USERNAME>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Creates a new internal only user account for batch/role access, such
|
||||
as from an automated build system or event monitoring over
|
||||
link:cmd-stream-events.html[gerrit stream-events].
|
||||
|
||||
If LDAP authentication is being used, the user account is created
|
||||
without checking the LDAP directory. Consequently users can be
|
||||
created in Gerrit that do not exist in the underlying LDAP directory.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
<USERNAME>::
|
||||
Required; SSH username of the user account.
|
||||
|
||||
\--ssh-key::
|
||||
Content of the public SSH key to load into the account's
|
||||
keyring. If `-` the key is read from stdin, rather than
|
||||
from the command line.
|
||||
|
||||
\--group::
|
||||
Name of the group to put the user into. Multiple \--group
|
||||
options may be specified to add the user to multiple groups.
|
||||
|
||||
\--full-name::
|
||||
Display name of the user account.
|
||||
+
|
||||
Names containing spaces should be quoted in single quotes (\').
|
||||
This most likely requires double quoting the value, for example
|
||||
`\--full-name "\'A description string\'"`.
|
||||
|
||||
\--email::
|
||||
Preferred email address for the user account.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
Create a new user account called `watcher`:
|
||||
|
||||
====
|
||||
$ cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit create-account --ssh-key - watcher
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
gerrit create-group
|
||||
===================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit create-group - Create a new account group.
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit create-group' \
|
||||
[\--owner <GROUP>] \
|
||||
[\--description <DESC>] \
|
||||
[\--member <USERNAME>] \
|
||||
[\--group <GROUP>] \
|
||||
<GROUP>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Creates a new account group. The group creating user (the user that
|
||||
fired the create-group command) is not automatically added to
|
||||
the created group. In case the creating user wants to be a member of
|
||||
the group he/she must list itself in the --member option. This is
|
||||
slightly different from Gerrit's Web UI where the creating user automatically
|
||||
becomes a member of the newly created group.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
<GROUP>::
|
||||
Required; name of the new group.
|
||||
|
||||
\--owner, -o::
|
||||
Name of the owning group. If not specified the group will be self-owning.
|
||||
|
||||
\--description, -d::
|
||||
Description of group.
|
||||
+
|
||||
Description values containing spaces should be quoted in single quotes
|
||||
(\'). This most likely requires double quoting the value, for example
|
||||
`\--description "\'A description string\'"`.
|
||||
|
||||
\--member::
|
||||
User name to become initial member of the group. Multiple \--member
|
||||
options may be specified to add more initial members.
|
||||
|
||||
\--group::
|
||||
Group name to include in the group. Multiple \--group options may
|
||||
be specified to include more initial groups.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
Create a new account group called `gerritdev` with two initial members
|
||||
`developer1` and `developer2`. The group should be owned by itself:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 user@review.example.com gerrit create-group --member developer1 --member developer2 gerritdev
|
||||
====
|
||||
|
||||
Create a new account group called `Foo` owned by the `Foo-admin` group.
|
||||
Put `developer1` as the initial member and include group description:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 user@review.example.com gerrit create-group --owner Foo-admin --member developer1 --description "'Foo description'" Foo
|
||||
====
|
||||
|
||||
Note that it is necessary to quote the description twice. The local
|
||||
shell needs double quotes around the value to ensure the single quotes
|
||||
are passed through SSH as-is to the remote Gerrit server, which uses
|
||||
the single quotes to delimit the value.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,156 +0,0 @@
|
|||
gerrit create-project
|
||||
=====================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit create-project - Create a new hosted project
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit create-project' \
|
||||
--name <NAME> \
|
||||
[--branch <REF>] \
|
||||
[\--owner <GROUP> ...] \
|
||||
[\--parent <NAME>] \
|
||||
[\--description <DESC>] \
|
||||
[\--submit-type <TYPE>] \
|
||||
[\--use-content-merge] \
|
||||
[\--use-contributor-agreements] \
|
||||
[\--use-signed-off-by] \
|
||||
[\--empty-commit]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Creates a new bare Git repository under `gerrit.basePath`, using
|
||||
the project name supplied. The newly created repository is empty
|
||||
(has no commits), but is registered in the Gerrit database so that
|
||||
the initial commit may be uploaded for review, or initial content
|
||||
can be pushed directly into a branch.
|
||||
|
||||
If replication is enabled, this command also connects to each of
|
||||
the configured remote systems over SSH and uses command line git
|
||||
on the remote system to create the empty repository.
|
||||
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of any of the groups defined by
|
||||
repository.*.createGroup in gerrit.config.
|
||||
|
||||
If there is no such declaration, caller is required to be a member
|
||||
of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--name::
|
||||
Required; name of the project to create. If name ends with
|
||||
`.git` the suffix will be automatically removed.
|
||||
|
||||
\--branch::
|
||||
Name of the initial branch in the newly created project.
|
||||
Defaults to 'master'.
|
||||
|
||||
\--owner::
|
||||
Name of the group(s) which will initially own this repository.
|
||||
The specified group(s) must already be defined within Gerrit.
|
||||
Several groups can be specified on the command line.
|
||||
+
|
||||
Defaults to what is specified by repository.*.ownerGroup
|
||||
in gerrit.config. If no such declaration(s) exist,
|
||||
repository.*.createGroup will be used. If they don't exist,
|
||||
`Administrators` will be used.
|
||||
|
||||
\--parent::
|
||||
Name of the parent project to inherit access rights
|
||||
through. If not specified, the parent is set to the default
|
||||
project `\-- All Projects \--`.
|
||||
|
||||
\--description::
|
||||
Initial description of the project. If not specified,
|
||||
no description is stored.
|
||||
+
|
||||
Description values containing spaces should be quoted in single quotes
|
||||
(\'). This most likely requires double quoting the value, for example
|
||||
`\--description "\'A description string\'"`.
|
||||
|
||||
\--submit-type::
|
||||
Action used by Gerrit to submit an approved change to its
|
||||
destination branch. Supported options are:
|
||||
+
|
||||
* FAST_FORWARD_ONLY: produces a strictly linear history.
|
||||
* MERGE_IF_NECESSARY: create a merge commit when required.
|
||||
* MERGE_ALWAYS: always create a merge commit.
|
||||
* CHERRY_PICK: always cherry-pick the commit.
|
||||
|
||||
+
|
||||
Defaults to MERGE_IF_NECESSARY. For more details see
|
||||
link:project-setup.html#submit_type[Change Submit Actions].
|
||||
|
||||
\--use-content-merge::
|
||||
If enabled, Gerrit will try to perform a 3-way merge of text
|
||||
file content when a file has been modified by both the
|
||||
destination branch and the change being submitted. This
|
||||
option only takes effect if submit type is not
|
||||
FAST_FORWARD_ONLY. Disabled by default.
|
||||
|
||||
\--use-contributor-agreements::
|
||||
If enabled, authors must complete a contributor agreement
|
||||
on the site before pushing any commits or changes to this
|
||||
project. Disabled by default.
|
||||
|
||||
\--use-signed-off-by::
|
||||
If enabled, each change must contain a Signed-off-by line
|
||||
from either the author or the uploader in the commit message.
|
||||
Disabled by default.
|
||||
|
||||
\--empty-commit:
|
||||
Creates an initial empty commit for the Git repository of the
|
||||
project that is newly created.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
Create a new project called `tools/gerrit`:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit create-project --name tools/gerrit.git
|
||||
====
|
||||
|
||||
Create a new project with a description:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit create-project --name tool.git --description "'Tools used by build system'"
|
||||
====
|
||||
|
||||
Note that it is necessary to quote the description twice. The local
|
||||
shell needs double quotes around the value to ensure the single quotes
|
||||
are passed through SSH as-is to the remote Gerrit server, which uses
|
||||
the single quotes to delimit the value.
|
||||
|
||||
REPLICATION
|
||||
-----------
|
||||
The remote repository creation is performed by a Bourne shell script:
|
||||
|
||||
====
|
||||
mkdir -p '/base/project.git' && cd '/base/project.git' && git init --bare && git update-ref HEAD refs/heads/master
|
||||
====
|
||||
|
||||
For this to work successfully the remote system must be able to run
|
||||
arbitrary shell scripts, and must have `git` in the user's PATH
|
||||
environment variable. Administrators could also run this command line
|
||||
by hand to establish a new empty repository.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:config-replication.html[Git Replication/Mirroring]
|
||||
* link:project-setup.html[Project Setup]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,103 +0,0 @@
|
|||
gerrit flush-caches
|
||||
===================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit flush-caches - Flush some/all server caches from memory
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit flush-caches' \
|
||||
[\--all | \--list | \--cache <NAME> ...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Clear an in-memory cache, forcing Gerrit to reconsult the ground
|
||||
truth when it needs the information again.
|
||||
|
||||
Flushing a cache may be necessary if an administrator modifies
|
||||
database records directly in the database, rather than going through
|
||||
the Gerrit web interface.
|
||||
|
||||
If no options are supplied, defaults to `--all`.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--all::
|
||||
Flush all known caches. This is like applying a big hammer,
|
||||
it will force everything out, potentially more than was
|
||||
necessary for the change made. This option automatically
|
||||
skips flushing potentially dangerous caches such as
|
||||
"web_sessions". To flush one of these caches, the caller
|
||||
must specifically name them on the command line, e.g. pass
|
||||
`\--cache=web_sessions`.
|
||||
|
||||
\--list::
|
||||
Show a list of the caches.
|
||||
|
||||
\--cache=<NAME>::
|
||||
Flush only the cache called <NAME>. May be supplied more
|
||||
than once to flush multiple caches in a single command
|
||||
execution.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
List caches available for flushing:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --list
|
||||
accounts
|
||||
accounts_byemail
|
||||
diff
|
||||
groups
|
||||
ldap_groups
|
||||
openid
|
||||
projects
|
||||
sshkeys
|
||||
web_sessions
|
||||
====
|
||||
|
||||
Flush all caches known to the server, forcing them to recompute:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --all
|
||||
====
|
||||
|
||||
or
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches
|
||||
====
|
||||
|
||||
Flush only the "sshkeys" cache, after manually editing an SSH key
|
||||
for a user:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys
|
||||
====
|
||||
|
||||
Flush "web_sessions", forcing all users to sign-in again:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache web_sessions
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:cmd-show-caches.html[gerrit show-caches]
|
||||
* link:config-gerrit.html#cache[Cache Configuration]
|
||||
* link:config-gerrit.html#cache_names[Standard Caches]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,62 +0,0 @@
|
|||
gerrit gsql
|
||||
===========
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit gsql - Administrative interface to active database
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit gsql' \
|
||||
[\--format \{PRETTY | JSON\}] \
|
||||
[\-c QUERY]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Provides interactive query support directly against the underlying
|
||||
SQL database used by the host Gerrit server. All SQL statements
|
||||
are supported, including SELECT, UPDATE, INSERT, DELETE and ALTER.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--format::
|
||||
Set the format records are output in. In PRETTY (the
|
||||
default) records are displayed in a tabular output suitable
|
||||
for reading by a human on a sufficiently wide terminal.
|
||||
In JSON mode records are output as JSON objects using the
|
||||
column names as the property names, one object per line.
|
||||
|
||||
-c::
|
||||
Execute the single query statement supplied, and then exit.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
Intended for interactive use only, unless format is JSON.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
To manually correct a user's SSH user name:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit gsql
|
||||
Welcome to Gerrit Code Review v2.0.25
|
||||
(PostgreSQL 8.3.8)
|
||||
|
||||
Type '\h' for help. Type '\r' to clear the buffer.
|
||||
|
||||
gerrit> update accounts set ssh_user_name = 'alice' where account_id=1;
|
||||
UPDATE 1; 1 ms
|
||||
gerrit> \q
|
||||
Bye
|
||||
|
||||
$ ssh -p 29418 review.example.com gerrit flush-caches --cache sshkeys --cache accounts
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
commit-msg Hook
|
||||
===============
|
||||
|
||||
NAME
|
||||
----
|
||||
commit-msg - Edit commit messages to insert a `Change-Id` tag.
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
A Git hook automatically invoked by `git commit`, and most other
|
||||
commit creation tools such as `git citool` or `git gui`. The Gerrit
|
||||
Code Review supplied implementation of this hook is a short shell
|
||||
script which automatically inserts a globally unique Change-Id tag
|
||||
in the footer of a commit message. When present, Gerrit uses this
|
||||
tag to track commits across cherry-picks and rebases.
|
||||
|
||||
After the hook has been installed in the user's local Git repository
|
||||
for a project, the hook will modify a commit message such as:
|
||||
|
||||
----
|
||||
Improve foo widget by attaching a bar.
|
||||
|
||||
We want a bar, because it improves the foo by providing more
|
||||
wizbangery to the dowhatimeanery.
|
||||
|
||||
Signed-off-by: A. U. Thor <author@example.com>
|
||||
----
|
||||
|
||||
by inserting a new `Change-Id: ` line in the footer:
|
||||
|
||||
----
|
||||
Improve foo widget by attaching a bar.
|
||||
|
||||
We want a bar, because it improves the foo by providing more
|
||||
wizbangery to the dowhatimeanery.
|
||||
|
||||
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b
|
||||
Signed-off-by: A. U. Thor <author@example.com>
|
||||
----
|
||||
|
||||
The hook implementation is reasonably intelligent at inserting the
|
||||
Change-Id line before any Signed-off-by or Acked-by lines placed
|
||||
at the end of the commit message by the author, but if no such
|
||||
lines are present then it will just insert a blank line, and add
|
||||
the Change-Id at the bottom of the message.
|
||||
|
||||
If a Change-Id line is already present in the message footer, the
|
||||
script will do nothing, leaving the existing Change-Id unmodified.
|
||||
This permits amending an existing commit, or allows the user to
|
||||
insert the Change-Id manually after copying it from an existing
|
||||
change viewed on the web.
|
||||
|
||||
OBTAINING
|
||||
---------
|
||||
To obtain the 'commit-msg' script use scp, wget or curl to copy it
|
||||
to your local system:
|
||||
|
||||
$ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg .git/hooks/
|
||||
|
||||
$ curl http://review.example.com/tools/hooks/commit-msg
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:user-changeid.html[Change-Id Lines]
|
||||
* link:http://www.kernel.org/pub/software/scm/git/docs/git-commit.html[git-commit(1)]
|
||||
* link:http://www.kernel.org/pub/software/scm/git/docs/githooks.html[githooks(5)]
|
||||
|
||||
IMPLEMENTATION
|
||||
--------------
|
||||
|
||||
The hook generates unique Change-Id lines by creating a virtual
|
||||
commit object within the local Git repository, and obtaining the
|
||||
SHA-1 hash from it. Like any other Git commit, the following
|
||||
properties are included in the computation:
|
||||
|
||||
* SHA-1 of the tree being committed
|
||||
* SHA-1 of the parent commit
|
||||
* Name, email address, timestamp of the author
|
||||
* Name, email address, timestamp of the committer
|
||||
* Proposed commit message (before Change-Id was inserted)
|
||||
|
||||
Because the names of the tree and parent commit, as well as the
|
||||
committer timestamp are included in the hash computation, the output
|
||||
Change-Id is sufficiently unique.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,125 +0,0 @@
|
|||
Gerrit Code Review - Command Line Tools
|
||||
=======================================
|
||||
|
||||
Client
|
||||
------
|
||||
|
||||
Client commands and hooks can be downloaded via scp, wget or curl
|
||||
from Gerrit's daemon, and then executed on the client system.
|
||||
|
||||
To download a client command or hook, use scp or an http client:
|
||||
|
||||
$ scp -p -P 29418 john.doe@review.example.com:bin/gerrit-cherry-pick ~/bin/
|
||||
$ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg .git/hooks/
|
||||
|
||||
$ curl http://review.example.com/tools/bin/gerrit-cherry-pick
|
||||
$ curl http://review.example.com/tools/hooks/commit-msg
|
||||
|
||||
For more details on how to determine the correct SSH port number,
|
||||
see link:user-upload.html#test_ssh[Testing Your SSH Connection].
|
||||
|
||||
[[client_commands]]Commands
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
link:cmd-cherry-pick.html[gerrit-cherry-pick]::
|
||||
Download and cherry-pick one or more changes (commits).
|
||||
|
||||
[[client_hooks]]Hooks
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Client hooks can be installed into a local Git repository, improving
|
||||
the developer experience when working with a Gerrit Code Review
|
||||
server.
|
||||
|
||||
link:cmd-hook-commit-msg.html[commit-msg]::
|
||||
Automatically generate `Change-Id: ` tags in commit messages.
|
||||
|
||||
|
||||
Server
|
||||
------
|
||||
|
||||
Aside from the standard Git server side actions, Gerrit supports
|
||||
several other commands over its internal SSH daemon. As Gerrit does
|
||||
not provide an interactive shell, the commands must be triggered
|
||||
from an ssh client, for example:
|
||||
|
||||
$ ssh -p 29418 review.example.com gerrit ls-projects
|
||||
|
||||
For more details on how to determine the correct SSH port number,
|
||||
see link:user-upload.html#test_ssh[Testing Your SSH Connection].
|
||||
|
||||
[[user_commands]]User Commands
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
git upload-pack::
|
||||
Standard Git server side command for client side `git fetch`.
|
||||
|
||||
link:cmd-receive-pack.html[git receive-pack]::
|
||||
Standard Git server side command for client side `git push`.
|
||||
+
|
||||
Also implements the magic associated with uploading commits for
|
||||
review. See link:user-upload.html#push_create[Creating Changes].
|
||||
|
||||
link:cmd-review.html[gerrit approve]::
|
||||
Alias for 'gerrit review'.
|
||||
|
||||
link:cmd-ls-projects.html[gerrit ls-projects]::
|
||||
List projects visible to the caller.
|
||||
|
||||
link:cmd-query.html[gerrit query]::
|
||||
Query the change database.
|
||||
|
||||
link:cmd-review.html[gerrit review]::
|
||||
Verify, approve and/or submit a patch set from the command line.
|
||||
|
||||
link:cmd-stream-events.html[gerrit stream-events]::
|
||||
Monitor events occuring in real time.
|
||||
|
||||
gerrit receive-pack::
|
||||
Legacy alias for `git receive-pack`.
|
||||
|
||||
[[admin_commands]]Adminstrator Commands
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
link:cmd-create-account.html[gerrit create-account]::
|
||||
Create a new batch/role account.
|
||||
|
||||
link:cmd-create-group.html[gerrit create-group]::
|
||||
Create a new account group.
|
||||
|
||||
link:cmd-create-project.html[gerrit create-project]::
|
||||
Create a new project and associated Git repository.
|
||||
|
||||
link:cmd-flush-caches.html[gerrit flush-caches]::
|
||||
Flush some/all server caches from memory.
|
||||
|
||||
link:cmd-gsql.html[gerrit gsql]::
|
||||
Administrative interface to active database.
|
||||
|
||||
link:cmd-set-project-parent.html[gerrit set-project-parent]::
|
||||
Change the project permissions are inherited from.
|
||||
|
||||
link:cmd-show-caches.html[gerrit show-caches]::
|
||||
Display current cache statistics.
|
||||
|
||||
link:cmd-show-connections.html[gerrit show-connections]::
|
||||
Display active client SSH connections.
|
||||
|
||||
link:cmd-show-queue.html[gerrit show-queue]::
|
||||
Display the background work queues, including replication.
|
||||
|
||||
link:cmd-replicate.html[gerrit replicate]::
|
||||
Manually trigger replication, to recover a node.
|
||||
|
||||
link:cmd-kill.html[kill]::
|
||||
Kills a scheduled or running task.
|
||||
|
||||
link:cmd-show-queue.html[ps]::
|
||||
Alias for 'gerrit show-queue'.
|
||||
|
||||
link:cmd-suexec.html[suexec]::
|
||||
Execute a command as any registered user account.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
kill
|
||||
====
|
||||
|
||||
NAME
|
||||
----
|
||||
kill - Cancel or abort a background task
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'kill' <ID> ...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Cancels a scheduled task from the queue. If the task has already
|
||||
been started, requests for the task to cancel as soon as it reaches
|
||||
its next cancellation point (which is usually blocking IO).
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
Intended for interactive use only.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
gerrit ls-projects
|
||||
==================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit ls-projects - List projects visible to caller
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit ls-projects' [\--show-branch <BRANCH1> ...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Displays the list of project names, one per line, that the
|
||||
calling user account has been granted 'READ' access to.
|
||||
|
||||
If the caller is a member of the privileged 'Administrators'
|
||||
group, all projects are listed.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Any user who has configured an SSH key.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--show-branch::
|
||||
\-b::
|
||||
Branch for which the command will display the sha of each project.
|
||||
The command may have multiple \--show-branch parameters, in this case
|
||||
sha will be shown for each of the branches.
|
||||
If the user does not have READ access to some branch or the branch does not
|
||||
exist then stub (forty '\-' symbols) is shown.
|
||||
If the user does not have access to any branch in the project then the
|
||||
whole project is not shown.
|
||||
|
||||
\--tree::
|
||||
\-t::
|
||||
Displays project inheritance in a tree-like format.
|
||||
This option does not work together with the show-branch option.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
List visible projects:
|
||||
=====
|
||||
$ ssh -p 29418 review.example.com gerrit ls-projects
|
||||
tools/gerrit
|
||||
tools/gwtorm
|
||||
=====
|
||||
|
||||
Clone any project visible to the user:
|
||||
====
|
||||
for p in `ssh -p 29418 review.example.com gerrit ls-projects`
|
||||
do
|
||||
mkdir -p `dirname "$p"`
|
||||
git clone --bare "ssh://review.example.com:29418/$p.git" "$p.git"
|
||||
done
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:access-control.html[Access Controls]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
gerrit query
|
||||
============
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit query - Query the change database
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit query' \
|
||||
[\--format {TEXT | JSON}] \
|
||||
[\--current-patch-set] \
|
||||
[\--patch-sets|--all-approvals] \
|
||||
[\--] \
|
||||
<query> \
|
||||
[limit:<n>] \
|
||||
[resume\_sortkey:<sortKey>]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Queries the change database and returns results describing changes
|
||||
that match the input query. More recently updated changes appear
|
||||
before older changes, which is the same order presented in the
|
||||
web interface.
|
||||
|
||||
A query may be limited on the number of results it returns with the
|
||||
'limit:' operator. If no limit is supplied an internal default
|
||||
limit is used to prevent explosion of the result set. To obtain
|
||||
results beyond the limit, the 'resume_sortkey:' operator can be used
|
||||
to resume the query at the change that follows the last change of
|
||||
the prior result set.
|
||||
|
||||
Non-option arguments to this command are joined with spaces and then
|
||||
parsed as a query. This simplifies calling conventions over SSH
|
||||
by permitting operators to appear in different arguments without
|
||||
multiple levels of quoting required.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--current-patch-set::
|
||||
Include information about the current patch set in the results.
|
||||
|
||||
\--patch-sets::
|
||||
Include information about all patch sets. If combined with
|
||||
the \--current-patch-set flag then the current patch set
|
||||
information will be output twice, once in each field.
|
||||
|
||||
\--all-approvals::
|
||||
Include information about all patch sets along with the
|
||||
approval information for each patch set. If combined with
|
||||
the \--current-patch-set flag then the current patch set
|
||||
information will be output twice, once in each field.
|
||||
|
||||
limit:<n>::
|
||||
Maximum number of results to return. This is actually a
|
||||
query operator, and not a command line option. If more
|
||||
than one limit: operator is provided, the smallest limit
|
||||
will be used to cut the result set.
|
||||
|
||||
resume\_sortkey:<sortKey>::
|
||||
Resume results from this sort key. Callers should pass
|
||||
the sortKey of the last change of the prior result set to
|
||||
resume a prior query. This is actually a query operator,
|
||||
and not a command line option.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Any user who has configured an SSH key.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Find the 2 most recent open changes in the tools/gerrit project:
|
||||
-----
|
||||
$ ssh -p 29418 review.example.com gerrit query --format=JSON status:open project:tools/gerrit limit:2
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"project":"tools/gerrit", ..., sortKey:"000e6aee00003e26", ...}
|
||||
{"type":"stats","rowCount":2,"runningTimeMilliseconds:15}
|
||||
-----
|
||||
|
||||
Resume the same query and obtain the final results:
|
||||
-----
|
||||
$ ssh -p 29418 review.example.com gerrit query --format=JSON status:open project:tools/gerrit limit:2 resume_sortkey:000e6aee00003e26
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"project":"tools/gerrit", ...}
|
||||
{"type":"stats","rowCount":1,"runningTimeMilliseconds:15}
|
||||
-----
|
||||
|
||||
|
||||
SCHEMA
|
||||
------
|
||||
The JSON messages consist of nested objects referencing the
|
||||
link:json.html#change[change],
|
||||
link:json.html#patchset[patchset],
|
||||
link:json.html#[account]
|
||||
involved, and other attributes as appropriate.
|
||||
|
||||
Note that any field may be missing in the JSON messages, so consumers
|
||||
of this JSON stream should deal with that appropriately.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:user-search.html[Query Operators]
|
||||
* link:json.html[JSON Data Formats]
|
||||
* link:access-control.html[Access Controls]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,105 +0,0 @@
|
|||
git-receive-pack
|
||||
================
|
||||
|
||||
NAME
|
||||
----
|
||||
git-receive-pack - Receive what is pushed into the repository
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
git receive-pack [\--reviewer <address>] [\--cc <address>] <project>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Invoked by 'git push' and updates the project's repository with
|
||||
the information fed from the 'git push' end.
|
||||
|
||||
End users can supply options to this command by passing them through
|
||||
to 'git push', which will relay them automatically.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
<project>::
|
||||
The remote repository that will receive the pushed objects,
|
||||
and create (or update) changes. Within Gerrit Code Review
|
||||
this is the name of a project. The optional leading `/`
|
||||
and or trailing `.git` suffix will be removed, if supplied.
|
||||
|
||||
\--re <address>::
|
||||
\--reviewer <address>::
|
||||
Automatically add <address> as a reviewer to any change
|
||||
created or updated by the pushed commit objects. These
|
||||
changes will appear in the reviewer's dashboard, and will
|
||||
also be emailed to the reviewer.
|
||||
+
|
||||
May be specified more than once to request multiple reviewers.
|
||||
+
|
||||
This is a Gerrit Code Review specific extension.
|
||||
|
||||
\--cc <address>::
|
||||
Carbon-copy <address> on the created or updated changes,
|
||||
but don't request them to perform a review. Like with
|
||||
\--reviewer the changes will appear in the CC'd user's
|
||||
dashboard, and will be emailed to them.
|
||||
+
|
||||
May be specified more than once to specify multiple CCs.
|
||||
+
|
||||
This is a Gerrit Code Review specific extension.
|
||||
|
||||
Above <address> may be the complete email address, or, if Gerrit is
|
||||
configured with HTTP authentication (e.g. within a single domain),
|
||||
just the local part (typically username).
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Any user who has configured an SSH key.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Send a review for a change on the master branch to charlie@example.com:
|
||||
=====
|
||||
git push --receive-pack='git receive-pack --reviewer charlie@example.com' ssh://review.example.com:29418/project HEAD:refs/for/master
|
||||
=====
|
||||
|
||||
Send reviews, but tagging them with the topic name 'bug42':
|
||||
=====
|
||||
git push --receive-pack='git receive-pack --reviewer charlie@example.com' ssh://review.example.com:29418/project HEAD:refs/for/master/bug42
|
||||
=====
|
||||
|
||||
Also CC two other parties:
|
||||
=====
|
||||
git push --receive-pack='git receive-pack --reviewer charlie@example.com --cc alice@example.com --cc bob@example.com' ssh://review.example.com:29418/project HEAD:refs/for/master
|
||||
=====
|
||||
|
||||
Configure a push macro to perform the last action:
|
||||
====
|
||||
git config remote.charlie.url ssh://review.example.com:29418/project
|
||||
git config remote.charlie.push HEAD:refs/for/master
|
||||
git config remote.charlie.receivepack 'git receive-pack --reviewer charlie@example.com --cc alice@example.com --cc bob@example.com'
|
||||
====
|
||||
|
||||
afterwards `.git/config` contains the following:
|
||||
====
|
||||
[remote "charlie"]
|
||||
url = ssh://review.example.com:29418/project
|
||||
push = HEAD:refs/for/master
|
||||
receivepack = git receive-pack --reviewer charlie@example.com --cc alice@example.com --cc bob@example.com
|
||||
====
|
||||
|
||||
and now sending a new change for review to charlie, CC'ing both
|
||||
alice and bob is much easier:
|
||||
====
|
||||
git push charlie
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:user-upload.html[Uploading Changes]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
gerrit replicate
|
||||
================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit replicate - Manually trigger replication, to recover a node
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit replicate' \
|
||||
[\--url <PATTERN>] \
|
||||
\{\--all | <PROJECT> ...}
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Schedules replication of the specified projects to all configured
|
||||
replication destinations, or only those whose URLs match the pattern
|
||||
given on the command line.
|
||||
|
||||
Normally Gerrit automatically schedules replication whenever it
|
||||
makes a change to a managed Git repository. However, there are
|
||||
other reasons why an administrator may wish to trigger replication:
|
||||
|
||||
* Destination disappears, then later comes back online.
|
||||
+
|
||||
If a destination went offline for a period of time, when it comes
|
||||
back, it may be missing commits that it should have. Triggering a
|
||||
replication run for all projects against that URL will update it.
|
||||
|
||||
* After repacking locally, and using `rsync` to distribute the new
|
||||
pack files to the destinations.
|
||||
+
|
||||
If the local server is repacked, and then the resulting pack files
|
||||
are sent to remote peers using `rsync -a \--delete-after`, there
|
||||
is a chance that the rsync missed a change that was added during
|
||||
the rsync data transfer, and the rsync will remove that changes's
|
||||
data from the remote, even though the automatic replication pushed
|
||||
it there in parallel to the rsync.
|
||||
+
|
||||
Its a good idea to run replicate with `\--all` to ensure all
|
||||
projects are consistent after the rsync is complete.
|
||||
|
||||
* After deleting a ref by hand.
|
||||
+
|
||||
If a ref must be removed (e.g. to purge a change or patch set
|
||||
that shouldn't have been created, and that must be eradicated)
|
||||
that delete must be done by direct git access on the local,
|
||||
managed repository. Gerrit won't know about the delete, and is
|
||||
unable to replicate it automatically. Triggering replication on
|
||||
just the affected project can update the mirrors.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--all::
|
||||
Schedule replicating for all projects.
|
||||
|
||||
\--url=<PATTERN>::
|
||||
Replicate only to replication destinations whose URL
|
||||
contains the substring <PATTERN>. This can be useful to
|
||||
replicate only to a previously down node, which has been
|
||||
brought back online.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
Replicate every project, to every configured remote:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit replicate --all
|
||||
====
|
||||
|
||||
Replicate only to `srv2` now that it is back online:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit replicate --url=srv2 --all
|
||||
====
|
||||
|
||||
Replicate only the `tools/gerrit` project, after deleting a ref
|
||||
locally by hand:
|
||||
|
||||
====
|
||||
$ git --git-dir=/home/git/tools/gerrit.git update-ref -d refs/changes/00/100/1
|
||||
$ ssh -p 29418 review.example.com gerrit replicate tools/gerrit
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:config-replication.html[Git Replication/Mirroring]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,111 +0,0 @@
|
|||
gerrit review
|
||||
==============
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit review - Verify, approve and/or submit one or more patch sets
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit approve' [\--project <PROJECT>] [\--message <MESSAGE>] [\--verified <N>] [\--code-review <N>] [\--abandon] [\--restore] [\--submit] {COMMIT | CHANGEID,PATCHSET}...
|
||||
'ssh' -p <port> <host> 'gerrit review' [\--project <PROJECT>] [\--message <MESSAGE>] [\--verified <N>] [\--code-review <N>] [\--abandon] [\--restore] [\--submit] {COMMIT | CHANGEID,PATCHSET}...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Updates the current user's approval status of the specified patch
|
||||
sets and/or submits them for merging, sending out email
|
||||
notifications and updating the database.
|
||||
|
||||
Patch sets should be specified as complete or abbreviated commit
|
||||
SHA-1s. If the same commit is available in multiple projects the
|
||||
\--project option may be used to limit where Gerrit searches for
|
||||
the change to only the contents of the specified project.
|
||||
|
||||
For current backward compatibility with user tools patch sets may
|
||||
also be specified in the legacy 'CHANGEID,PATCHSET' format, such as
|
||||
'8242,2'. Support for this legacy format is planned to be removed
|
||||
in a future edition of Gerrit Code Review. Use of commit SHA-1s
|
||||
is strongly encouraged.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
\--project::
|
||||
-p::
|
||||
Name of the project the intended changes are contained
|
||||
within. This option must be supplied before the commit
|
||||
SHA-1 in order to take effect.
|
||||
|
||||
\--message::
|
||||
-m::
|
||||
Optional cover letter to include as part of the message
|
||||
sent to reviewers when the approval states are updated.
|
||||
|
||||
\--help::
|
||||
-h::
|
||||
Display site-specific usage information, including the
|
||||
complete listing of supported approval categories and values.
|
||||
|
||||
\--code-review::
|
||||
\--verified::
|
||||
Set the approval category to the value 'N'. The exact
|
||||
option names supported and the range of values permitted
|
||||
differs per site, check the output of \--help, or contact
|
||||
your site administrator for further details.
|
||||
|
||||
\--abandon::
|
||||
Abandon the specified patch set(s).
|
||||
(option is mutually exclusive with --submit and --restore)
|
||||
|
||||
\--restore::
|
||||
Restore the specified abandonned patch set(s).
|
||||
(option is mutually exclusive with --abandon)
|
||||
|
||||
\--submit::
|
||||
-s::
|
||||
Submit the specified patch set(s) for merging.
|
||||
(option is mutually exclusive with --abandon)
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Any user who has configured an SSH key.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Approve the change with commit c0ff33 as "Verified +1"
|
||||
=====
|
||||
$ ssh -p 29418 review.example.com gerrit review --verified=+1 c0ff33
|
||||
=====
|
||||
|
||||
Append the message "Build Successful". Notice two levels of quoting is
|
||||
required, one for the local shell, and another for the argument parser
|
||||
inside the Gerrit server:
|
||||
=====
|
||||
$ ssh -p 29418 review.example.com gerrit review -m '"Build Successful"'
|
||||
=====
|
||||
|
||||
Mark the unmerged commits both "Verified +1" and "Code Review +2" and
|
||||
submit them for merging:
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit review \
|
||||
--verified=+1 \
|
||||
--code-review=+2 \
|
||||
--submit \
|
||||
--project=this/project \
|
||||
$(git rev-list origin/master..HEAD)
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:access-control.html[Access Controls]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
gerrit set-project-parent
|
||||
=========================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit set-project-parent - Change the project permissions are inherited from.
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit set-project-parent' \
|
||||
[\--parent <NAME>] \
|
||||
<NAME> ...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Changes the project that permissions are inherited through.
|
||||
Every project inherits permissions from another project, by
|
||||
default this is `\-- All Projects \--`. This command sets
|
||||
the project to inherit through another one.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--parent::
|
||||
Name of the parent to inherit through. If not specified,
|
||||
the parent is set back to the default `\-- All Projects \--`.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
Configure `kernel/omap` to inherit permissions from `kernel/common`:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit set-project-parent --parent kernel/common kernel/omap
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:access-control.html[Access Controls]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,62 +0,0 @@
|
|||
gerrit show-caches
|
||||
===================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit show-caches - Display current cache statistics
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit show-caches'
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Display statistics about the size and hit ratio of in-memory caches.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
Intended for interactive use only.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit show-caches
|
||||
Name Max |Object Count | AvgGet |Hit Ratio |
|
||||
Age | Disk Mem Cnt| |Disk Mem Agg |
|
||||
-------------------------+--------------------+----------+--------------+
|
||||
accounts 90d | 295| | 99%|
|
||||
accounts_byemail 90d | 109| | 97%|
|
||||
D diff 90d | 2695 128 2707| 0.4ms | 11% 86% 98%|
|
||||
groups 90d | 94| | 80%|
|
||||
openid 5m | 30| 0.4ms | 9%|
|
||||
projects 90d | 188| | 99%|
|
||||
sshkeys 90d | 9| | 94%|
|
||||
D web_sessions 12h | 30 30| | 0% 99% 99%|
|
||||
|
||||
JGit Buffer Cache:
|
||||
open files : 23
|
||||
loaded : 6.82 mb
|
||||
mem% : 2%
|
||||
|
||||
JVM Heap:
|
||||
max : 880.00 mb
|
||||
inuse : 136.57 mb
|
||||
mem% : 44%
|
||||
====
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:cmd-flush-caches.html[gerrit flush-caches]
|
||||
* link:config-gerrit.html#cache[Cache Configuration]
|
||||
* link:config-gerrit.html#cache_names[Standard Caches]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
gerrit show-connections
|
||||
=======================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit show-connections - Display active client SSH connections
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit show-connections' [-n]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Presents a table of the active SSH connections, the users who
|
||||
are currently connected to the internal server and performing
|
||||
an activity.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
Intended for interactive use only.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
-n::
|
||||
\--numeric::
|
||||
Show client hostnames as IP addresses instead of DNS hostname.
|
||||
|
||||
DISPLAY
|
||||
-------
|
||||
|
||||
Session::
|
||||
Unique session identifier on this server. Session
|
||||
identifiers have a period of 2\^32-1 and start from a
|
||||
random value.
|
||||
|
||||
Start::
|
||||
Time (local to the server) that this connection started.
|
||||
|
||||
Idle::
|
||||
Time since the last data transfer on this connection.
|
||||
Note that most SSH clients use not only a TCP based
|
||||
connection keep-alive, but also an encrypted keep alive
|
||||
higher up in the SSH protocol stack. That higher keep
|
||||
alive resets the idle timer, about once a minute.
|
||||
|
||||
User::
|
||||
The username of the account that is authenticated on this
|
||||
connection. If the -n option is used, this column shows
|
||||
the Account Id instead.
|
||||
|
||||
Remote Host::
|
||||
Reverse lookup hostname, or if -n option is used, the remote
|
||||
IP address.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
With reverse DNS lookup (default):
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit show-connections
|
||||
Session Start Idle User Remote Host
|
||||
--------------------------------------------------------------
|
||||
3abf31e6 20:09:02 00:00:00 jdoe jdoe-desktop.example.com
|
||||
--
|
||||
====
|
||||
|
||||
Without reverse DNS lookup:
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit show-connections -n
|
||||
Session Start Idle User Remote Host
|
||||
--------------------------------------------------------------
|
||||
3abf31e6 20:09:02 00:00:00 a/1001240 10.0.0.1
|
||||
--
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
gerrit show-queue
|
||||
=================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit show-queue - Display the background work queues, including replication
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'ps'
|
||||
'ssh' -p <port> <host> 'gerrit show-queue'
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Presents a table of the pending activity the Gerrit daemon
|
||||
is currently performing, or will perform in the near future.
|
||||
Gerrit contains an internal scheduler, similar to cron, that it
|
||||
uses to queue and dispatch both short and long term activity.
|
||||
|
||||
Tasks that are completed or cancelled exit the queue very quickly
|
||||
once they enter this state, but it can be possible to observe tasks
|
||||
in these states.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be a member of the privileged 'Administrators' group.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
Intended for interactive use only.
|
||||
|
||||
DISPLAY
|
||||
-------
|
||||
|
||||
Task::
|
||||
Unique task identifier on this server. May be passed into
|
||||
link:cmd-kill.html[kill] to cancel or terminate the task.
|
||||
Task identifiers have a period of 2\^32-1, and start from
|
||||
a random value.
|
||||
|
||||
State::
|
||||
If running, blank.
|
||||
+
|
||||
If the task has completed, but has not yet been reaped, 'done'.
|
||||
If the task has been killed, but has not yet halted or been removed
|
||||
from the queue, 'killed'.
|
||||
+
|
||||
If the task is ready to execute but is waiting for an idle thread
|
||||
in its associated thread pool, 'waiting'.
|
||||
+
|
||||
Otherwise the time (local to the server) that this task will begin
|
||||
execution.
|
||||
|
||||
Command::
|
||||
Short text description of the task that will be performed
|
||||
at the given time.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
The following queue contains two tasks scheduled to replicate the
|
||||
`tools/gerrit.git` project to two different remote systems, `dst1`
|
||||
and `dst2`:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 review.example.com gerrit show-queue
|
||||
Task State Command
|
||||
------------------------------------------------------------------------------
|
||||
7aae09b2 14:31:15.435 mirror dst1:/home/git/tools/gerrit.git
|
||||
9ad09d27 14:31:25.434 mirror dst2:/var/cache/tools/gerrit.git
|
||||
------------------------------------------------------------------------------
|
||||
2 tasks
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,122 +0,0 @@
|
|||
gerrit stream-events
|
||||
====================
|
||||
|
||||
NAME
|
||||
----
|
||||
gerrit stream-events - Monitor events occuring in real time
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> <host> 'gerrit stream-events'
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Provides a portal into the major events occuring on the server,
|
||||
outputing activity data in real-time to the client. Events are
|
||||
filtered by the caller's access permissions, ensuring the caller
|
||||
only receives events for changes they can view on the web, or in
|
||||
the project repository.
|
||||
|
||||
Event output is in JSON, one event per line.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Any user who has configured an SSH key.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
-----
|
||||
$ ssh -p 29418 review.example.com gerrit stream-events
|
||||
{"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
|
||||
{"type":"comment-added",change:{"project":"tools/gerrit", ...}, ...}
|
||||
-----
|
||||
|
||||
SCHEMA
|
||||
------
|
||||
The JSON messages consist of nested objects referencing the *change*,
|
||||
*patchset*, *account* involved, and other attributes as appropriate.
|
||||
The currently supported message types are *patchset-created*,
|
||||
*comment-added*, *change-merged*, and *change-abandoned*.
|
||||
|
||||
Note that any field may be missing in the JSON messages, so consumers of
|
||||
this JSON stream should deal with that appropriately.
|
||||
|
||||
Events
|
||||
~~~~~~
|
||||
Patchset Created
|
||||
^^^^^^^^^^^^^^^^
|
||||
type:: "patchset-created"
|
||||
|
||||
change:: link:json.html#change[change attribute]
|
||||
|
||||
patchset:: link:json.html#patchset[patchset attribute]
|
||||
|
||||
uploader:: link:json.html#account[account attribute]
|
||||
|
||||
Change Abandoned
|
||||
^^^^^^^^^^^^^^^^
|
||||
type:: "change-abandoned"
|
||||
|
||||
change:: link:json.html#change[change attribute]
|
||||
|
||||
patchset:: link:json.html#patchset[patchset attribute]
|
||||
|
||||
abandoner:: link:json.html#account[account attribute]
|
||||
|
||||
Change Restored
|
||||
^^^^^^^^^^^^^^^^
|
||||
type:: "change-restored"
|
||||
|
||||
change:: link:json.html#change[change attribute]
|
||||
|
||||
patchset:: link:json.html#patchset[patchset attribute]
|
||||
|
||||
restorer:: link:json.html#account[account attribute]
|
||||
|
||||
Change Merged
|
||||
^^^^^^^^^^^^^
|
||||
type:: "change-merged"
|
||||
|
||||
change:: link:json.html#change[change attribute]
|
||||
|
||||
patchset:: link:json.html#patchset[patchset attribute]
|
||||
|
||||
submitter:: link:json.html#account[account attribute]
|
||||
|
||||
Comment Added
|
||||
^^^^^^^^^^^^^
|
||||
type:: "comment-added"
|
||||
|
||||
change:: link:json.html#change[change attribute]
|
||||
|
||||
patchset:: link:json.html#patchset[patchset attribute]
|
||||
|
||||
author:: link:json.html#account[account attribute]
|
||||
|
||||
comment:: Comment text author had written
|
||||
|
||||
Ref Updated
|
||||
^^^^^^^^^^^
|
||||
type:: "ref-updated"
|
||||
|
||||
submitter:: link:json.html#account[account attribute]
|
||||
|
||||
refUpdate:: link:json.html#refupdate[refupdate attribute]
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:json.html[JSON Data Formats]
|
||||
* link:access-control.html[Access Controls]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
suexec
|
||||
======
|
||||
|
||||
NAME
|
||||
----
|
||||
suexec - Execute a command as any registered user account
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'ssh' -p <port> 'Gerrit Code Review'@localhost -i <private host key> 'suexec' \--as <EMAIL> [\--from HOST:PORT] [\--] [COMMAND]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
The suexec command can only be invoked by the magic user Gerrit Code Review
|
||||
and permits executing any other command as any other registered user account.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
\--as::
|
||||
Email address of the user you want to impersonate.
|
||||
\--from::
|
||||
Hostname and port of the machine you want to impersonate the command
|
||||
coming from.
|
||||
COMMAND::
|
||||
Gerrit command you want to run.
|
||||
|
||||
ACCESS
|
||||
------
|
||||
Caller must be the magic user Gerrit Code Review using the SSH daemon's host key
|
||||
or a key on this daemon's peer host key ring.
|
||||
|
||||
SCRIPTING
|
||||
---------
|
||||
This command is intended to be used in scripts.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
||||
Approve the change with commit c0ff33 as "Verified +1" as user bob@example.com
|
||||
=====
|
||||
$ sudo -u gerrit ssh -p 29418 -i site_path/etc/ssh_host_rsa_key \
|
||||
'Gerrit Code Review'@localhost suexec --as bob@example.com -- \
|
||||
gerrit approve --verified=+1 c0ff33
|
||||
=====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,215 +0,0 @@
|
|||
Gerrit Code Review - Contact Information
|
||||
========================================
|
||||
|
||||
To help ensure contributor privacy, but still support gathering of
|
||||
contributor agreements as necessary, Gerrit encrypts all offline
|
||||
contact information gathered from users. This data is shipped to
|
||||
another server, typically at a different location, to make it more
|
||||
difficult for an attacker to obtain.
|
||||
|
||||
This feature is optional. If the crypto APIs aren't installed
|
||||
and the `contactstore.url` setting in `gerrit.config` is not set,
|
||||
Gerrit will not collect contact information from users.
|
||||
|
||||
|
||||
Setup
|
||||
-----
|
||||
|
||||
Ensure Bouncy Castle Crypto API is available in the web application's
|
||||
CLASSPATH (e.g. in `'JETTY_HOME'/lib/plus` for Jetty). Gerrit needs
|
||||
both `bcprov-jdk\*-*.jar` and `bcpg-jdk\*-*.jar` to be provided
|
||||
for the contact encryption to work.
|
||||
|
||||
* link:http://www.bouncycastle.org/latest_releases.html[Bouncy Castle Crypto API]
|
||||
|
||||
Ensure a proper JCE policy file is installed. By default most
|
||||
JRE installations forbid the use of a strong key, resulting in
|
||||
SecurityException messages when trying to encrypt the contact data.
|
||||
You need to obtain a strong JCE policy file and install it by hand.
|
||||
Look for the 'Unlimited Strength Jurisdiction Policy' download.
|
||||
|
||||
* link:http://java.sun.com/javase/downloads/index.jsp[Java SE Downloads]
|
||||
|
||||
Create a public/private key pair for contact data handling.
|
||||
Generate the keys on a protected system, where the resulting
|
||||
private key is unlikely to fall into the wrong hands.
|
||||
|
||||
====
|
||||
gpg --gen-key
|
||||
====
|
||||
|
||||
Select to use a `DSA and Elgamal` key type, as the public key will
|
||||
be used for data encryption.
|
||||
|
||||
The information chosen for name, email and comment fields can be
|
||||
anything reasonable which would identify the contact store of this
|
||||
Gerrit instance. It is probably a good idea to not use a real
|
||||
person's name here, but instead some sort of organizational role.
|
||||
The actual values chosen don't matter later, and are only to help
|
||||
document the purpose of the key.
|
||||
|
||||
Chose a fairly long expiration period, such as 20 years. For most
|
||||
Gerrit instances, contact data will be written once, and rarely,
|
||||
if ever, read back.
|
||||
|
||||
Export the public key for Gerrit to use during encryption. The
|
||||
public key must be stored in a file called `contact_information.pub`
|
||||
and reside inside of the `site_config` directory. Armoring it
|
||||
during export makes it easier to transport between systems, as
|
||||
you can easily copy-and-paste the text. Gerrit can read both the
|
||||
armored and unarmored formats.
|
||||
|
||||
====
|
||||
gpg --export --armor KEYEMAIL >$site_path/etc/contact_information.pub
|
||||
====
|
||||
|
||||
Consider storing the private key with some sort of key escrow
|
||||
service within your organization. Without the private key it
|
||||
is impossible to recover contact records.
|
||||
|
||||
Install a contact store implementation somewhere to receive
|
||||
the contact records. To be really paranoid, Gerrit always
|
||||
ships the data to another HTTP server, preferrably over HTTPS.
|
||||
Existing open-source server implementations can be found in the
|
||||
gerrit-contactstore project.
|
||||
|
||||
* link:http://android.git.kernel.org/?p=tools/gerrit-contactstore.git[gerrit-contactstore]
|
||||
|
||||
Configure `'$site_path'/etc/gerrit.config` with the contact store's
|
||||
URL (in `contactstore.url`), and if needed, APPSEC value (in
|
||||
`contactstore.appsec`):
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config appsec.url https://...
|
||||
git config --file $site_path/etc/gerrit.config appsec.appsec sekret
|
||||
====
|
||||
|
||||
|
||||
Contact Store Protocol
|
||||
----------------------
|
||||
|
||||
To implement a new contact store, the following details are useful.
|
||||
|
||||
Gerrit connects to the contact store by sending a standard
|
||||
`application/x-www-form-urlencoded` within an HTTP POST request
|
||||
sent to the store URL (the exact URL that is in contactstore.url)
|
||||
with the following form fields in the body:
|
||||
|
||||
* APPSEC
|
||||
+
|
||||
A shared secret "password" that should be known only to Gerrit
|
||||
and the contact store. The contact store should test this value to
|
||||
deter spamming of the contact store by outside parties. Gerrit reads
|
||||
this from contactstore.appsec.
|
||||
|
||||
* account_id
|
||||
+
|
||||
Unique account_id value from the Gerrit database for the account
|
||||
the contact information belongs to. Base 10 integer.
|
||||
|
||||
* email
|
||||
+
|
||||
Preferred email address of the account. May facilitate lookups in
|
||||
the contact store at a future date. May be omitted or the empty
|
||||
string if the user hasn't chosen a preferred email.
|
||||
|
||||
* filed
|
||||
+
|
||||
Seconds since the UNIX epoch of when the contact information
|
||||
was filed. May be omitted or the empty string if Gerrit
|
||||
doesn't think the supplied contact information is valid enough.
|
||||
|
||||
* data
|
||||
+
|
||||
Encrypted account data as an armored ASCII blob. This is usually
|
||||
several KB of text data as a single string, with embedded newlines
|
||||
to break the lines at about 70-75 characters per line. Data can
|
||||
be decoded using GnuPG with the correct private key.
|
||||
|
||||
Upon successful store, the contact store application should respond
|
||||
with HTTP status code `200` and a body consisting only of `OK`
|
||||
(or `OK\n`). Any other response code or body is considered to be
|
||||
a failure by Gerrit.
|
||||
|
||||
Using `https://` for the store URL is *highly* encouraged, as it
|
||||
prevents man-in-the-middle attacks from reading the shared secret
|
||||
APPSEC token, or messing with the data field.
|
||||
|
||||
Data Format
|
||||
~~~~~~~~~~~
|
||||
|
||||
Once decrypted the `data` field looks something like the following:
|
||||
|
||||
----
|
||||
Account-Id: 1001240
|
||||
Date: 2009-02-23 20:32:32.852 UTC
|
||||
Full-Name: John Doe
|
||||
Preferred-Email: jdoe@example.com
|
||||
Identity: jd15@some-isp.com
|
||||
Identity: jdoe@example.com <https://www.google.com/accounts/o8/id?id=AIt18axxafvda821aQZaHDF1k8akbalk218sak>
|
||||
Identity: jdoe@example.com <http://jdoe.blogger.com/>
|
||||
Address:
|
||||
123 Any Street
|
||||
Any Town, Somewhere
|
||||
Country: USA
|
||||
Phone-Number: +1 (555) 555-1212
|
||||
Fax-Number: 555.1200
|
||||
----
|
||||
|
||||
The fields are as follows:
|
||||
|
||||
* `Account-Id`
|
||||
+
|
||||
Value of the `account_id` field in the metadata database. This is
|
||||
a unique key for this account, and links all data records to it.
|
||||
|
||||
* `Date`
|
||||
+
|
||||
Date and time of when this contact record was submitted by the user.
|
||||
Written in an ISO formatted date/time string (`YYYY-MM-DD hh:mm:ss`),
|
||||
in the UTC timezone.
|
||||
|
||||
* `Full-Name`
|
||||
+
|
||||
The `full_name` field of the account record when the user submitted
|
||||
the contact information. This should be the user's given name and
|
||||
family name.
|
||||
|
||||
* `Preferred-Email`
|
||||
+
|
||||
The `preferred_email` field of the account record when the user
|
||||
submitted the contact information. This should be one of the emails
|
||||
listed in the `Identity` field.
|
||||
|
||||
* `Identity`
|
||||
+
|
||||
This field occurs once for each `account_external_id` record
|
||||
in the database for this account. The email address is listed,
|
||||
and if the user is using OpenID authentication, the OpenID claimed
|
||||
identity follows in brackets (`<...>`). Identity lines without an
|
||||
OpenID identity are usually created by sending an email containing
|
||||
a unique hyperlink that the user must visit to setup the identity.
|
||||
|
||||
* `Address`
|
||||
+
|
||||
Free form text, as entered by the user. This should describe some
|
||||
location that physical documents could be sent to, but it is not
|
||||
verified, so users can enter pretty much anything here. Each line
|
||||
is prefixed with a single TAB character, but is otherwise exactly
|
||||
as entered.
|
||||
|
||||
* `Country`
|
||||
+
|
||||
Free form text, as entered by the user. This should be some sort
|
||||
of country name or ISO country abbreviation, but it is not verified,
|
||||
so it can be pretty much anything.
|
||||
|
||||
* `Phone-Number`, `Fax-Number`
|
||||
+
|
||||
Free form text, as entered by the user. The format here can be
|
||||
anything, and as the example shows, may not even be consistent in
|
||||
the same record.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,122 +0,0 @@
|
|||
Gerrit Code Review - Gitweb Integration
|
||||
=======================================
|
||||
|
||||
Gerrit Code Review can manage and generate hyperlinks to gitweb,
|
||||
allowing users to jump from Gerrit content to the same information,
|
||||
but shown by gitweb.
|
||||
|
||||
|
||||
Internal/Managed gitweb
|
||||
-----------------------
|
||||
|
||||
In the internal configuration, Gerrit inspects the request, enforces
|
||||
its project level access controls, and directly executes `gitweb.cgi`
|
||||
if the user is authorized to view the page.
|
||||
|
||||
To enable the internal configuration, set
|
||||
link:config-gerrit.html#gitweb.cgi[gitweb.cgi] with the path of the
|
||||
installed CGI. This defaults to `/usr/lib/cgi-bin/gitweb.cgi`,
|
||||
which is a common installation path for the 'gitweb' package on
|
||||
Linux distributions.
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
|
||||
git config --file $site_path/etc/gerrit.config --unset gitweb.url
|
||||
====
|
||||
|
||||
Alternatively, if Gerrit is served behind reverse proxy, it can
|
||||
generate different URLs for gitweb's links (they need to be
|
||||
rewritten to `<gerrit>/gitweb?args` on the web server). This allows
|
||||
for serving gitweb under different URL than the Gerrit instance.
|
||||
To enable this feature, set both: `gitweb.cgi` and `gitweb.url`.
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
|
||||
git config --file $site_path/etc/gerrit.config gitweb.url /pretty/path/to/gitweb
|
||||
====
|
||||
|
||||
After updating `'$site_path'/etc/gerrit.config`, the Gerrit server must
|
||||
be restarted and clients must reload the host page to see the change.
|
||||
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Most of the gitweb configuration file is handled automatically
|
||||
by Gerrit Code Review. Site specific overrides can be placed in
|
||||
`'$site_path'/etc/gitweb_config.perl`, as this file is loaded as
|
||||
part of the generated configuration file.
|
||||
|
||||
Logo and CSS
|
||||
~~~~~~~~~~~~
|
||||
|
||||
If the package-manager installed CGI (`/usr/lib/cgi-bin/gitweb.cgi`)
|
||||
is being used, the stock CSS and logo files will be served from
|
||||
either `/usr/share/gitweb` or `/var/www`.
|
||||
|
||||
Otherwise, Gerrit expects `gitweb.css` and `git-logo.png` to be found
|
||||
in the same directory as the CGI script itself. This matches with
|
||||
the default source code distribution, and most custom installations.
|
||||
|
||||
Access Control
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Access controls for internally managed gitweb page views are enforced
|
||||
using the standard project READ +1 permission.
|
||||
|
||||
|
||||
External/Unmanaged gitweb
|
||||
-------------------------
|
||||
|
||||
In the external configuration, gitweb runs under the control of an
|
||||
external web server, and Gerrit access controls are not enforced.
|
||||
|
||||
To enable the external gitweb integration, set
|
||||
link:config-gerrit.html#gitweb.url[gitweb.url] with the URL of your
|
||||
gitweb CGI.
|
||||
|
||||
The CGI's `$projectroot` should be the same directory as
|
||||
gerrit.basePath, or a fairly current replica. If a replica is
|
||||
being used, ensure it uses a full mirror, so the `refs/changes/*`
|
||||
namespace is available.
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config gitweb.url http://example.com/gitweb.cgi
|
||||
git config --file $site_path/etc/gerrit.config --unset gitweb.cgi
|
||||
====
|
||||
|
||||
After updating `'$site_path'/etc/gerrit.config`, the Gerrit server must
|
||||
be restarted and clients must reload the host page to see the change.
|
||||
|
||||
Access Control
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Gitweb access controls can be implemented using standard web server
|
||||
access controls. This isn't typically integrated with Gerrit's own
|
||||
access controls. Caution must be taken to ensure the controls are
|
||||
consistent if access needs to be restricted.
|
||||
|
||||
Caching Gitweb
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
If your repository set is large and you are expecting a lot
|
||||
of users, you may want to look at the caching forks used by
|
||||
high-traffic sites like kernel.org or repo.or.cz.
|
||||
|
||||
Alternatives to gitweb
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
There are other alternatives to gitweb that can also be used with
|
||||
Gerrit, such as cgit.
|
||||
|
||||
cgit can be used by specifying `gitweb.type` to be 'cgit'.
|
||||
|
||||
It is also possible to define custom patterns.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
* link:config-gerrit.html#gitweb[Section gitweb]
|
||||
* link:http://hjemli.net/git/cgit/[cgit]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
Gerrit Code Review - Site Customization
|
||||
=======================================
|
||||
|
||||
Gerrit supports some customization of the HTML it sends to
|
||||
the browser, allowing organizations to alter the look and
|
||||
feel of the application to fit with their general scheme.
|
||||
|
||||
HTML Header/Footer
|
||||
------------------
|
||||
|
||||
At startup Gerrit reads the following files (if they exist) and
|
||||
uses them to customize the HTML page it sends to clients:
|
||||
|
||||
* `'$site_path'/etc/GerritSiteHeader.html`
|
||||
+
|
||||
HTML is inserted below the menu bar, but above any page content.
|
||||
This is a good location for an organizational logo, or links to
|
||||
other systems like bug tracking.
|
||||
|
||||
* `'$site_path'/etc/GerritSiteFooter.html`
|
||||
+
|
||||
HTML is inserted at the bottom of the page, below all other content,
|
||||
but just above the footer rule and the "Powered by Gerrit Code
|
||||
Review (v....)" message shown at the extreme bottom.
|
||||
|
||||
* `'$site_path'/etc/GerritSite.css`
|
||||
+
|
||||
The CSS rules are inlined into the top of the HTML page, inside
|
||||
of a `<style>` tag. These rules can be used to support styling
|
||||
the elements within either the header or the footer.
|
||||
|
||||
The *.html files must be valid XHTML, with one root element,
|
||||
typically a single `<div>` tag. The server parses it as XML, and
|
||||
then inserts the root element into the host page. If a file has
|
||||
more than one root level element, Gerrit will not start.
|
||||
|
||||
Static Images
|
||||
-------------
|
||||
|
||||
Static image files can also be served from `'$site_path'/static`,
|
||||
and may be referenced in `GerritSite{Header,Footer}.html`
|
||||
or `GerritSite.css` by the relative URL `static/$name`
|
||||
(e.g. `static/logo.png`).
|
||||
|
||||
To simplify security management, only files are served from
|
||||
`'$site_path'/static`. Subdirectories are explicitly forbidden from
|
||||
being served from this location by enforcing the rule that file names
|
||||
cannot contain `/` or `\`. (Client requests for `static/foo/bar`
|
||||
will result in 404 Not Found responses.)
|
||||
|
||||
HTTP Caching
|
||||
------------
|
||||
|
||||
The header, footer, and CSS files are inlined into the host page,
|
||||
which is always sent with a no-cache header. Clients will see any
|
||||
changes immediately after they are made.
|
||||
|
||||
Assets under `'$site_path'/static` whose file name matches one of the
|
||||
following patterns are served with a 1 year expiration, permitting
|
||||
very aggressive caching by clients and edge-proxies:
|
||||
|
||||
* `*.cache.html`
|
||||
* `*.cache.gif`
|
||||
* `*.cache.png`
|
||||
* `*.cache.css`
|
||||
* `*.cache.jar`
|
||||
* `*.cache.swf`
|
||||
|
||||
All other assets under `'$site_path'/static` are served with a 5
|
||||
minute expire, permitting some (limited) caching. It may take up
|
||||
to 5 minutes after making a change, before clients see the changes.
|
||||
|
||||
It is recommended that static images used in the site header
|
||||
or footer be named with a unique caching file name, for example
|
||||
`my_logo1.cache.png`, to allow browsers to take advantage of their
|
||||
disk cache. If the image needs to be modified, create a new file,
|
||||
`my_logo2.cache.png` and update the header (or footer) HTML to
|
||||
reference the new image path.
|
||||
|
||||
Google Analytics Integration
|
||||
----------------------------
|
||||
|
||||
To connect Gerrit to Google Analytics add the following to your
|
||||
`GerritSiteFooter.html`:
|
||||
|
||||
====
|
||||
<div>
|
||||
<!-- standard analytics code -->
|
||||
<script type="text/javascript">
|
||||
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
|
||||
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
|
||||
</script>
|
||||
<script type="text/javascript">
|
||||
var pageTracker = _gat._getTracker("UA-nnnnnnn-n");
|
||||
pageTracker._trackPageview();
|
||||
</script>
|
||||
<!-- /standard analytics code -->
|
||||
|
||||
<script type="text/javascript">
|
||||
window.onload = function() {
|
||||
gerrit_addHistoryHook(function (s) {
|
||||
pageTracker._trackPageview(s.replace(/#/, '/'))
|
||||
});
|
||||
};
|
||||
</script>
|
||||
</div>
|
||||
====
|
||||
|
||||
Please consult the Google Analytics documentation for the correct
|
||||
setup code (the first two script tags). The above is shown only
|
||||
as a reference example.
|
||||
|
||||
If your footer is otherwise empty, wrap all of the script tags into
|
||||
a single `<div>` tag (like above) to ensure it is a well-formed
|
||||
XHTML document file.
|
||||
|
||||
The global function `gerrit_addHistoryHook` accepts functions that
|
||||
accept a string parameter. These functions are put into a list and
|
||||
invoked any time Gerrit shifts URLs. You'll see page names like
|
||||
`/#change,123` be passed to these functions, which in turn
|
||||
are handed off to Google Analytics for tracking. Our example hook
|
||||
above replaces '#' with '/' because Analytics won't track anchors.
|
||||
|
||||
The `window.onload` callback is necessary to ensure that the
|
||||
`gerrit_addHistoryHook` function has actually been defined by the
|
||||
page. Because GWT loads the module asynchronously any `<script>`
|
||||
block in the header or footer will execute before Gerrit has defined
|
||||
the function and is ready to register the hook callback.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,106 +0,0 @@
|
|||
Gerrit Code Review - Hooks
|
||||
==========================
|
||||
|
||||
Gerrit does not run any of the standard git hooks in the
|
||||
repositories it works with, but it does have its own hook mechanism
|
||||
included. Gerrit looks in `'$site_path'/hooks` for executables with
|
||||
names listed below.
|
||||
|
||||
The environment will have GIT_DIR set to the full path of the
|
||||
affected git repository so that git commands can be easily run.
|
||||
|
||||
Make sure your hook scripts are executable if running on *nix.
|
||||
|
||||
Hooks are run in the background after the relevent change has
|
||||
taken place so are unable to affect the outcome of any given
|
||||
change. Because of the fact the hooks are run in the background
|
||||
after the activity, a hook might not be notified about an event if
|
||||
the server is shutdown before the hook can be invoked.
|
||||
|
||||
Supported Hooks
|
||||
---------------
|
||||
|
||||
patchset-created
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
This is called whenever a patchset is created (this includes new
|
||||
changes)
|
||||
|
||||
====
|
||||
patchset-created --change <change id> --change-url <change url> --project <project name> --branch <branch> --uploader <uploader> --commit <sha1> --patchset <patchset id>
|
||||
====
|
||||
|
||||
comment-added
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
This is called whenever a comment is added to a change.
|
||||
|
||||
====
|
||||
comment-added --change <change id> --change-url <change url> --project <project name> --branch <branch> --author <comment author> --commit <commit> --comment <comment> [--<approval category id> <score> --<approval category id> <score> ...]
|
||||
====
|
||||
|
||||
change-merged
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Called whenever a change has been merged.
|
||||
|
||||
====
|
||||
change-merged --change <change id> --change-url <change url> --project <project name> --branch <branch> --submitter <submitter> --commit <sha1>
|
||||
====
|
||||
|
||||
change-abandoned
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Called whenever a change has been abandoned.
|
||||
|
||||
====
|
||||
change-abandoned --change <change id> --change-url <change url> --project <project name> --branch <branch> --abandoner <abandoner> --reason <reason>
|
||||
====
|
||||
|
||||
change-restored
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Called whenever a change has been restored.
|
||||
|
||||
====
|
||||
change-restored --change <change id> --change-url <change url> --project <project name> --branch <branch> --restorer <restorer> --reason <reason>
|
||||
====
|
||||
|
||||
ref-updated
|
||||
~~~~~~~~~~~
|
||||
|
||||
Called whenever a ref has been updated.
|
||||
|
||||
====
|
||||
ref-updated --oldrev <old rev> --newrev <new rev> --refname <ref name> --project <project name> --submitter <submitter>
|
||||
====
|
||||
|
||||
|
||||
Configuration Settings
|
||||
----------------------
|
||||
|
||||
It is possible to change where gerrit looks for hooks, and what
|
||||
filenames it looks for by adding a [hooks] section to gerrit.config.
|
||||
|
||||
Gerrit will use the value of hooks.path for the hooks directory, and
|
||||
the values of hooks.patchsetCreatedHook, hooks.commentAddedHook,
|
||||
hooks.changeMergedHook and hooks.changeAbandonedHook for the
|
||||
filenames for the hooks.
|
||||
|
||||
Missing Change URLs
|
||||
-------------------
|
||||
|
||||
If link:config-gerrit.html#gerrit.canonicalWebUrl[gerrit.canonicalWebUrl]
|
||||
is not set in `gerrit.config` the `\--change-url` flag may not be
|
||||
passed to all hooks. Hooks started out of an SSH context (for example
|
||||
the patchset-created hook) don't know the server's web URL, unless
|
||||
this variable is configured.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
* link:config-gerrit.html#hooks[Section hooks]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,172 +0,0 @@
|
|||
Gerrit Code Review - Mail Templates
|
||||
===================================
|
||||
|
||||
Gerrit uses velocity templates for the bulk of the standard mails it sends out.
|
||||
There are builtin default templates which are used if they are not overridden.
|
||||
These defaults are also provided as examples so that administrators may copy
|
||||
them and easily modify them to tweak their contents.
|
||||
|
||||
|
||||
Template Locations and Extensions:
|
||||
----------------------------------
|
||||
|
||||
The default example templates reside under: `'$site_path'/etc/mail` and are
|
||||
terminated with the double extension `.vm.example`. Modifying these example
|
||||
files will have no effect on the behavior of Gerrit. However, copying an
|
||||
example template to an equivalently named file without the `.example` extension
|
||||
and modifying it will allow an administrator to customize the template.
|
||||
|
||||
|
||||
Supported Mail Templates:
|
||||
-------------------------
|
||||
|
||||
Each mail that Gerrit sends out is controlled by at least one template, these
|
||||
are listed below. Change emails are influenced by two additional templates,
|
||||
one to set the subject line, and one to set the footer which gets appended to
|
||||
all the change emails (see `ChangeSubject.vm` and `ChangeFooter.vm` below.)
|
||||
|
||||
Abandoned.vm
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The `Abandoned.vm` template will determine the contents of the email related
|
||||
to a change being abandoned. It is a `ChangeEmail`: see `ChangeSubject.vm` and
|
||||
`ChangeFooter.vm`.
|
||||
|
||||
ChangeFooter.vm
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The `ChangeFooter.vm` template will determine the contents of the footer
|
||||
text that will be appended to emails related to changes (all `ChangeEmails)`.
|
||||
|
||||
ChangeSubject.vm
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The `ChangeSubject.vm` template will determine the contents of the email
|
||||
subject line for ALL emails related to changes.
|
||||
|
||||
Comment.vm
|
||||
~~~~~~~~~~
|
||||
|
||||
The `Comment.vm` template will determine the contents of the email related to
|
||||
a user submitting comments on changes. It is a `ChangeEmail`: see
|
||||
|
||||
Merged.vm
|
||||
~~~~~~~~~
|
||||
|
||||
The `Merged.vm` template will determine the contents of the email related to
|
||||
a change successfully merged to the head. It is a `ChangeEmail`: see
|
||||
`ChangeSubject.vm` and `ChangeFooter.vm`.
|
||||
|
||||
MergeFail.vm
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The `MergeFail.vm` template will determine the contents of the email related
|
||||
to a failure upon attempting to merge a change to the head. It is a
|
||||
|
||||
NewChange.vm
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The `NewChange.vm` template will determine the contents of the email related
|
||||
to a user submitting a new change for review. It is a `ChangeEmail`: see
|
||||
`ChangeSubject.vm` and `ChangeFooter.vm`.
|
||||
|
||||
RegisterNewEmail.vm
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `RegisterNewEmail.vm` template will determine the contents of the email
|
||||
related to registering new email accounts.
|
||||
|
||||
ReplacePatchSet.vm
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The `ReplacePatchSet.vm` template will determine the contents of the email
|
||||
related to a user submitting a new patchset for a change. It is a
|
||||
`ChangeEmail`: see `ChangeSubject.vm` and `ChangeFooter.vm`.
|
||||
|
||||
|
||||
Mail Variables and Methods
|
||||
--------------------------
|
||||
|
||||
Mail templates can access and display objects currently made available to them
|
||||
via the velocity context. While the base objects are documented here, it is
|
||||
possible to call public methods on these objects from templates. Those methods
|
||||
are not documented here since they could change with every release. As these
|
||||
templates are meant to be modified only by a qualified sysadmin, it is accepted
|
||||
that writing templates for Gerrit emails is likely to require some basic
|
||||
knowledge of the class structure to be useful. Browsing the source code might
|
||||
be necessary for anything more than a minor formatting change.
|
||||
|
||||
Warning
|
||||
~~~~~~~
|
||||
|
||||
Be aware that modifying templates can cause them to fail to parse and therefor
|
||||
not send out the actual email, or worse, calling methods on the available
|
||||
objects could have internal side effects which would adversely affect the
|
||||
health of your Gerrit server and/or data.
|
||||
|
||||
All OutgoingEmails
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
All outgoing emails have the following variables available to them:
|
||||
|
||||
$email::
|
||||
+
|
||||
A reference to the class constructing the current `OutgoingEmail`. With this
|
||||
reference it is possible to call any public method on the OutgoingEmail class
|
||||
or the current child class inherited from it.
|
||||
|
||||
$messageClass::
|
||||
+
|
||||
A String containing the messageClass
|
||||
|
||||
$StringUtils::
|
||||
+
|
||||
A reference to the Apache `StringUtils` class. This can be very useful for
|
||||
formatting strings.
|
||||
|
||||
Change Emails
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
All change related emails have the following additional variables available to them:
|
||||
|
||||
$change::
|
||||
+
|
||||
A reference to the current `Change` object
|
||||
|
||||
$changeId::
|
||||
+
|
||||
Id of the current change (a `Change.Key`)
|
||||
|
||||
$coverLetter::
|
||||
+
|
||||
The text of the `ChangeMessage`
|
||||
|
||||
$branch::
|
||||
+
|
||||
A reference to the branch of this change (a `Branch.NameKey`)
|
||||
|
||||
$fromName::
|
||||
+
|
||||
The name of the from user
|
||||
|
||||
$projectName::
|
||||
+
|
||||
The name of this change's project
|
||||
|
||||
$patchSet::
|
||||
+
|
||||
A reference to the current `PatchSet`
|
||||
|
||||
$patchSetInfo::
|
||||
+
|
||||
A reference to the current `PatchSetInfo`
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
* link:http://velocity.apache.org/[velocity]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,253 +0,0 @@
|
|||
Gerrit Code Review - Git Replication
|
||||
====================================
|
||||
|
||||
Gerrit can automatically push any changes it makes to its managed Git
|
||||
repositories to another system. Usually this would be configured to
|
||||
provide mirroring of changes, for warm-standby backups, or a
|
||||
load-balanced public mirror farm.
|
||||
|
||||
The replication runs on a short delay. This gives Gerrit a small
|
||||
time window to batch updates going to the same project, such as
|
||||
when a user uploads multiple changes at once.
|
||||
|
||||
Typically replication should be done over SSH, with a passwordless
|
||||
public/private key pair. On a trusted network it is also possible to
|
||||
use replication over the insecure (but much faster) git:// protocol,
|
||||
by enabling the `receive-pack` service on the receiving system, but
|
||||
this configuration is not recommended.
|
||||
|
||||
Enabling Replication
|
||||
--------------------
|
||||
|
||||
If replicating over SSH (recommended), ensure the host key of the
|
||||
remote system(s) is already in the Gerrit user's `~/.ssh/known_hosts`
|
||||
file. The easiest way to add the host key is to connect once by hand
|
||||
with the command line:
|
||||
|
||||
====
|
||||
sudo su -c 'ssh mirror1.us.some.org echo' gerrit2
|
||||
====
|
||||
|
||||
Next, create `'$site_path'/replication.config` as a Git-style config
|
||||
file, and restart Gerrit.
|
||||
|
||||
Example `replication.config` to replicate in parallel to four
|
||||
different hosts:
|
||||
|
||||
====
|
||||
[remote "host-one"]
|
||||
url = gerrit2@host-one.example.com:/some/path/${name}.git
|
||||
|
||||
[remote "pubmirror"]
|
||||
url = mirror1.us.some.org:/pub/git/${name}.git
|
||||
url = mirror2.us.some.org:/pub/git/${name}.git
|
||||
url = mirror3.us.some.org:/pub/git/${name}.git
|
||||
push = +refs/heads/*:refs/heads/*
|
||||
push = +refs/tags/*:refs/tags/*
|
||||
threads = 3
|
||||
authGroup = Public Mirror Group
|
||||
authGroup = Second Public Mirror Group
|
||||
====
|
||||
|
||||
To manually trigger replication at runtime, see
|
||||
link:cmd-replicate.html[gerrit replicate].
|
||||
|
||||
[[replication_config]]File `replication.config`
|
||||
-----------------------------------------------
|
||||
|
||||
The optional file `'$site_path'/replication.config` is a Git-style
|
||||
config file that controls the replication settings for Gerrit.
|
||||
|
||||
The file is composed of one or more `remote` sections, each remote
|
||||
section provides common configuration settings for one or more
|
||||
destination URLs.
|
||||
|
||||
Each remote section uses its own thread pool. If pushing to
|
||||
multiple remotes, over differing types of network connections
|
||||
(e.g. LAN and also public Internet), its a good idea to put them
|
||||
into different remote sections, so that replication to the slower
|
||||
connection does not starve out the faster local one. The example
|
||||
file above does this.
|
||||
|
||||
[[remote]]Section remote
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In the keys below, the <name> portion is unused by Gerrit, but must be
|
||||
unique to distinguish the different sections if more than one remote
|
||||
section appears in the file.
|
||||
|
||||
[[remote.name.url]]remote.<name>.url::
|
||||
+
|
||||
Address of the remote server to push to. Multiple URLs may
|
||||
be specified within a single remote block, listing different
|
||||
destinations which share the same settings. Assuming sufficient
|
||||
threads in the thread pool, Gerrit pushes to all URLs in parallel,
|
||||
using one thread per URL.
|
||||
+
|
||||
Within each URL value the magic placeholder `$\{name}` is replaced
|
||||
with the Gerrit project name. This is a Gerrit specific extension
|
||||
to the otherwise standard Git URL syntax and it must be included
|
||||
in each URL so that Gerrit can figure out where each project needs
|
||||
to be replicated.
|
||||
+
|
||||
See link:http://www.kernel.org/pub/software/scm/git/docs/git-push.html#URLS[GIT URLS]
|
||||
for details on Git URL syntax.
|
||||
|
||||
[[remote.name.url]]remote.<name>.adminUrl::
|
||||
+
|
||||
Address of the alternative remote server only for repository creation. Multiple URLs may
|
||||
be specified within a single remote block, listing different
|
||||
destinations which share the same settings.
|
||||
+
|
||||
The adminUrl can be used as a ssh alternative to the url option, but only related to repository creation.
|
||||
If not specified, the repository creation tries to follow the default way through the url value specified.
|
||||
+
|
||||
It is useful when remote.<name>.url protocols does not allow repository creation
|
||||
although their usage are mandatory in the local environment.
|
||||
In that case, an alternative ssh url could be specified to repository creation.
|
||||
|
||||
[[remote.name.receivepack]]remote.<name>.receivepack::
|
||||
+
|
||||
Path of the `git-receive-pack` executable on the remote system, if
|
||||
using the SSH transport.
|
||||
+
|
||||
Defaults to `git-receive-pack`.
|
||||
|
||||
[[remote.name.uploadpack]]remote.<name>.uploadpack::
|
||||
+
|
||||
Path of the `git-upload-pack` executable on the remote system, if
|
||||
using the SSH transport.
|
||||
+
|
||||
Defaults to `git-upload-pack`.
|
||||
|
||||
[[remote.name.push]]remote.<name>.push::
|
||||
+
|
||||
Standard Git refspec denoting what should be replicated. Setting this
|
||||
to `+refs/heads/\*:refs/heads/\*` would mirror only the active
|
||||
branches, but not the change refs under `refs/changes/`, or the tags
|
||||
under `refs/tags/`.
|
||||
+
|
||||
Multiple push keys can be supplied, to specify multiple patterns
|
||||
to match against. In the example file above, remote "pubmirror"
|
||||
uses two push keys to match both `refs/heads/\*` and `refs/tags/*`,
|
||||
but excludes all others, including `refs/changes/*`.
|
||||
+
|
||||
Defaults to `+refs/\*:refs/*` (all refs) if not specified.
|
||||
|
||||
[[remote.name.timeout]]remote.<name>.timeout::
|
||||
+
|
||||
Number of seconds to wait for a network read or write to complete
|
||||
before giving up and declaring the remote side is not responding.
|
||||
If 0, there is no timeout, and the push client waits indefinitely.
|
||||
+
|
||||
A timeout should be large enough to mostly transfer the objects to
|
||||
the other side. 1 second may be too small for larger projects,
|
||||
especially over a WAN link, while 10-30 seconds is a much more
|
||||
reasonable timeout value.
|
||||
+
|
||||
Defaults to 0 seconds, wait indefinitely.
|
||||
|
||||
[[remote.name.replicationDelay]]remote.<name>.replicationDelay::
|
||||
+
|
||||
Number of seconds to wait before scheduling a remote push operation.
|
||||
Setting the delay to 0 effectively disables the delay, causing the
|
||||
push to start as soon as possible.
|
||||
+
|
||||
This is a Gerrit specific extension to the Git remote block.
|
||||
+
|
||||
By default, 15 seconds.
|
||||
|
||||
[[remote.name.replicationRetry]]remote.<name>.replicationRetry::
|
||||
+
|
||||
Number of minutes to wait before scheduling a remote push operation
|
||||
previously failed due to an offline remote server.
|
||||
+
|
||||
If a remote push operation fails because a remote server was
|
||||
offline, all push operations to the same destination URL are
|
||||
blocked, and the remote push is continuously retried.
|
||||
+
|
||||
This is a Gerrit specific extension to the Git remote block.
|
||||
+
|
||||
By default, 1 minute.
|
||||
|
||||
[[remote.name.threads]]remote.<name>.threads::
|
||||
+
|
||||
Number of worker threads to dedicate to pushing to the repositories
|
||||
described by this remote. Each thread can push one project at a
|
||||
time, to one destination URL. Scheduling within the thread pool
|
||||
is done on a per-project basis. If a remote block describes 4
|
||||
URLs, allocating 4 threads in the pool will permit some level of
|
||||
parallel pushing.
|
||||
+
|
||||
By default, 1 thread.
|
||||
|
||||
[[remote.name.authGroup]]remote.<name>.authGroup::
|
||||
+
|
||||
Specifies the name of a group that the remote should use to access
|
||||
the repositories. Multiple authGroups may be specified within a
|
||||
single remote block to signify a wider access right. In the project
|
||||
administration web interface the read access can be specified for
|
||||
this group to control if a project should be replicated or not to the
|
||||
remote.
|
||||
+
|
||||
By default, replicates without group control, i.e replicates
|
||||
everything to all remotes.
|
||||
|
||||
|
||||
[[secure_config]]File `secure.config`
|
||||
-----------------------------------------------
|
||||
|
||||
The optional file `'$site_path'/secure.config` is a Git-style config
|
||||
file that provides secure values that should not be world-readable,
|
||||
such as passwords. Passwords for HTTP remotes can be obtained from
|
||||
this file.
|
||||
|
||||
[[remote.name.username]]remote.<name>.username::
|
||||
+
|
||||
Username to use for HTTP authentication on this remote, if not given
|
||||
in the URL.
|
||||
|
||||
[[remote.name.password]]remote.<name>.password::
|
||||
+
|
||||
Password to use for HTTP authentication on this remote.
|
||||
|
||||
|
||||
[[ssh_config]]File `~/.ssh/config`
|
||||
----------------------------------
|
||||
|
||||
If present, Gerrit reads and caches `~/.ssh/config` at startup, and
|
||||
supports most SSH configuration options. For example:
|
||||
|
||||
====
|
||||
Host host-one.example.com:
|
||||
IdentityFile ~/.ssh/id_hostone
|
||||
PreferredAuthentications publickey
|
||||
|
||||
Host mirror*.us.some.org:
|
||||
User mirror-updater
|
||||
IdentityFile ~/.ssh/id_pubmirror
|
||||
PreferredAuthentications publickey
|
||||
====
|
||||
|
||||
Supported options:
|
||||
|
||||
* Host
|
||||
* Hostname
|
||||
* User
|
||||
* Port
|
||||
* IdentityFile
|
||||
* PreferredAuthentications
|
||||
* StrictHostKeyChecking
|
||||
|
||||
SSH authentication must be by passwordless public key, as there is
|
||||
no facility to read passphases on startup or passwords during the
|
||||
SSH connection setup, and SSH agents are not supported from Java.
|
||||
|
||||
Host keys for any destination SSH servers must appear in the user's
|
||||
`~/.ssh/known_hosts` file, and must be added in advance, before
|
||||
Gerrit starts. If a host key is not listed, Gerrit will be unable to
|
||||
connect to that destination, and replication to that URL will fail.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,128 +0,0 @@
|
|||
Gerrit Code Review - Reverse Proxy
|
||||
==================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Gerrit can be configured to run behind a third-party web server.
|
||||
This allows the other web server to bind to the privileged ports 80
|
||||
(or 443 for SSL), as well as offloads the SSL processing overhead
|
||||
from Java to optimized native C code.
|
||||
|
||||
|
||||
Gerrit Configuration
|
||||
--------------------
|
||||
|
||||
Ensure `'$site_path'/etc/gerrit.config` has the property
|
||||
link:config-gerrit.html#httpd.listenUrl[httpd.listenUrl] configured
|
||||
to use 'proxy-http://' or 'proxy-https://' and a free port number.
|
||||
This may have already been configured if proxy support was enabled
|
||||
during 'init'.
|
||||
|
||||
----
|
||||
[httpd]
|
||||
listenUrl = proxy-http://127.0.0.1:8081/r/
|
||||
----
|
||||
|
||||
|
||||
Apache 2 Configuration
|
||||
----------------------
|
||||
|
||||
To run Gerrit behind an Apache server using 'mod_proxy', enable the
|
||||
necessary Apache2 modules:
|
||||
|
||||
----
|
||||
a2enmod proxy_http
|
||||
a2enmod ssl ; # optional, needed for HTTPS / SSL
|
||||
----
|
||||
|
||||
Configure an Apache VirtualHost to proxy to the Gerrit daemon,
|
||||
setting the 'ProxyPass' line to use the 'http://' URL configured
|
||||
above. Ensure the path of ProxyPass and httpd.listenUrl match,
|
||||
or links will redirect to incorrect locations.
|
||||
|
||||
----
|
||||
<VirtualHost *>
|
||||
ServerName review.example.com
|
||||
|
||||
ProxyRequests Off
|
||||
ProxyVia Off
|
||||
ProxyPreserveHost On
|
||||
|
||||
<Proxy *>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Proxy>
|
||||
|
||||
ProxyPass /r/ http://127.0.0.1:8081/r/
|
||||
</VirtualHost>
|
||||
----
|
||||
|
||||
SSL
|
||||
~~~
|
||||
|
||||
To enable Apache to perform the SSL processing, use 'proxy-https://'
|
||||
in httpd.listenUrl within Gerrit's configuration file, and enable
|
||||
the SSL engine in the Apache VirtualHost block:
|
||||
|
||||
----
|
||||
<VirtualHost *:443>
|
||||
SSLEngine on
|
||||
SSLCertificateFile conf/server.crt
|
||||
SSLCertificateKeyFile conf/server.key
|
||||
|
||||
... same as above ...
|
||||
</VirtualHost>
|
||||
----
|
||||
|
||||
See the Apache 'mod_ssl' documentation for more details on how to
|
||||
configure SSL within the server, like controlling how strong of an
|
||||
encryption algorithm is required.
|
||||
|
||||
|
||||
Nginx Configuration
|
||||
-------------------
|
||||
|
||||
To run Gerrit behind an Nginx server, use a server statement such
|
||||
as this one:
|
||||
|
||||
----
|
||||
server {
|
||||
listen 80;
|
||||
server_name review.example.com;
|
||||
|
||||
location /r/ {
|
||||
proxy_pass http://127.0.0.1:8081;
|
||||
proxy_set_header X-Forwarded-For $remote_addr;
|
||||
proxy_set_header Host $host;
|
||||
}
|
||||
}
|
||||
----
|
||||
|
||||
SSL
|
||||
~~~
|
||||
|
||||
To enable Nginx to perform the SSL processing, use 'proxy-https://'
|
||||
in httpd.listenUrl within Gerrit's configuration file, and enable
|
||||
the SSL engine in the Nginx server statement:
|
||||
|
||||
----
|
||||
server {
|
||||
listen 443;
|
||||
server_name review.example.com;
|
||||
|
||||
ssl on;
|
||||
ssl_certificate conf/server.crt;
|
||||
ssl_certificate_key conf/server.key;
|
||||
|
||||
... same as above ...
|
||||
}
|
||||
----
|
||||
|
||||
See the Nginx 'http ssl module' documentation for more details on
|
||||
how to configure SSL within the server, like controlling how strong
|
||||
of an encryption algorithm is required.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,181 +0,0 @@
|
|||
Gerrit Code Review - Single Sign-On Security
|
||||
============================================
|
||||
|
||||
Gerrit supports integration with some types of single sign-on
|
||||
security solutions, making it possible for end-users to setup
|
||||
and manage accounts, without administrator involvement.
|
||||
|
||||
OpenID
|
||||
------
|
||||
|
||||
By default a new Gerrit installation relies upon OpenID to perform
|
||||
user authentication services. To enable OpenID, the auth.type
|
||||
setting should be `OpenID`:
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config auth.type OpenID
|
||||
====
|
||||
|
||||
As this is the default setting there is nothing required from the
|
||||
site administrator to make use of the OpenID authentication services.
|
||||
|
||||
* http://openid.net/[openid.net]
|
||||
|
||||
If Jetty is being used, you may need to increase the header
|
||||
buffer size parameter, due to very long header lines.
|
||||
Add the following to `$JETTY_HOME/etc/jetty.xml` under
|
||||
`org.mortbay.jetty.nio.SelectChannelConnector`:
|
||||
|
||||
====
|
||||
<Set name="headerBufferSize">16384</Set>
|
||||
====
|
||||
|
||||
In order to use permissions beyond those granted to the
|
||||
`Anonymous Users` and `Registered Users` groups, an account
|
||||
must only have OpenIDs which match at least one pattern from the
|
||||
`auth.trustedOpenID` list in `gerrit.config`. Patterns may be
|
||||
either a
|
||||
link:http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html[standard
|
||||
Java regular expression (java.util.regex)] (must start with `^`
|
||||
and end with `$`) or be a simple prefix (any other string).
|
||||
|
||||
Out of the box Gerrit is configured to trust two patterns, which
|
||||
will match any OpenID provider on the Internet:
|
||||
|
||||
* `http://` -- trust all OpenID providers using the HTTP protocol
|
||||
* `https://` -- trust all OpenID providers using the HTTPS protocol
|
||||
|
||||
To trust only Google Accounts:
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config auth.trustedOpenID 'https://www.google.com/accounts/o8/id?id='
|
||||
====
|
||||
|
||||
Database Schema
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
User identities obtained from OpenID providers are stored into the
|
||||
`account_external_ids` table. Users may link more than one OpenID
|
||||
identity to the same Gerrit account (use Settings, Web Identities
|
||||
to manage this linking), making it easier for their browser to sign
|
||||
in to Gerrit if they are frequently switching between different
|
||||
unique OpenID accounts.
|
||||
|
||||
|
||||
HTTP Basic/Digest Authentication
|
||||
--------------------------------
|
||||
|
||||
When using HTTP authentication, Gerrit assumes that the servlet
|
||||
container or the frontend web server has performed all user
|
||||
authentication prior to handing the request off to Gerrit.
|
||||
|
||||
As a result of this assumption, Gerrit can assume that any and
|
||||
all requests have already been authenticated. The "Sign In" and
|
||||
"Sign Out" links are therefore not displayed in the web UI.
|
||||
|
||||
To enable this form of authentication:
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config auth.type HTTP
|
||||
git config --file $site_path/etc/gerrit.config --unset auth.httpHeader
|
||||
git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
|
||||
====
|
||||
|
||||
The auth.type must always be HTTP, indicating the user identity
|
||||
will be obtained from the HTTP authorization data.
|
||||
|
||||
The auth.httpHeader must always be unset. If set to any value
|
||||
(including `Authorization`) then Gerrit won't correctly honor the
|
||||
standard `Authorization` HTTP header.
|
||||
|
||||
The auth.emailFormat field ('optional') sets the preferred email
|
||||
address during first login. Gerrit will replace `\{0\}` with the
|
||||
username, as obtained from the Authorization header. A format such
|
||||
as shown in the example would be typical, to add the domain name
|
||||
of the organization.
|
||||
|
||||
If Apache HTTPd is being used as the primary web server and the
|
||||
Apache server will be handling user authentication, a configuration
|
||||
such as the following is recommended to ensure Apache performs the
|
||||
authentication at the proper time:
|
||||
|
||||
====
|
||||
<Location "/login/">
|
||||
AuthType Basic
|
||||
AuthName "Gerrit Code Review"
|
||||
Require valid-user
|
||||
...
|
||||
</Location>
|
||||
====
|
||||
|
||||
Database Schema
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
User identities are stored in the `account_external_ids` table.
|
||||
The user string obtained from the authorization header has the prefix
|
||||
"gerrit:" and is stored in the `external_id` field. For example,
|
||||
if a username was "foo" then the external_id field would be populated
|
||||
with "gerrit:foo".
|
||||
|
||||
|
||||
Computer Associates Siteminder
|
||||
------------------------------
|
||||
|
||||
Siteminder is a commercial single sign on solution marketed by
|
||||
Computer Associates. It is very common in larger enterprise
|
||||
environments.
|
||||
|
||||
When using Siteminder, Gerrit assumes it has been installed in a
|
||||
servlet container which is running behind an Apache web server,
|
||||
and that the Siteminder authentication module has been configured
|
||||
within Apache to protect the entire Gerrit application. In this
|
||||
configuration all users must authenticate with Siteminder before
|
||||
they can access any resource on Gerrit.
|
||||
|
||||
As a result of this assumption, Gerrit can assume that any and
|
||||
all requests have already been authenticated. The "Sign In" and
|
||||
"Sign Out" links are therefore not displayed in the web UI.
|
||||
|
||||
To enable this form of authentication:
|
||||
|
||||
====
|
||||
git config --file $site_path/etc/gerrit.config auth.type HTTP
|
||||
git config --file $site_path/etc/gerrit.config auth.httpHeader SM_USER
|
||||
git config --file $site_path/etc/gerrit.config auth.emailFormat '{0}@example.com'
|
||||
====
|
||||
|
||||
The auth.type must always be HTTP, indicating the user identity
|
||||
will be obtained from the HTTP authorization data.
|
||||
|
||||
The auth.httpHeader indicates which HTTP header field the Siteminder
|
||||
product has stored the username. Usually this is "SM_USER", but
|
||||
may differ in your environment. Please refer to your organization's
|
||||
single sign-on or security group to ensure the setting is correct.
|
||||
|
||||
The auth.emailFormat field ('optional') sets the user's preferred
|
||||
email address when they first login. Gerrit will replace `\{0\}`
|
||||
with the username, as supplied by Siteminder. A format such as
|
||||
shown in the example would be typical, to add the domain name of
|
||||
the organization.
|
||||
|
||||
If Jetty is being used, you may need to increase the header
|
||||
buffer size parameter, due to very long header lines.
|
||||
Add the following to `$JETTY_HOME/etc/jetty.xml` under
|
||||
`org.mortbay.jetty.nio.SelectChannelConnector`:
|
||||
|
||||
====
|
||||
<Set name="headerBufferSize">16384</Set>
|
||||
====
|
||||
|
||||
|
||||
Database Schema
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
User identities are stored in the `account_external_ids` table.
|
||||
The user string obtained from Siteminder (e.g. the value in the
|
||||
"SM_USER" HTTP header) has the prefix "gerrit:" and is stored in the
|
||||
`external_id` field. For example, if a Siteminder username was "foo"
|
||||
then the external_id field would be populated with "gerrit:foo".
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,733 +0,0 @@
|
|||
Gerrit Code Review - System Design
|
||||
==================================
|
||||
|
||||
Objective
|
||||
---------
|
||||
|
||||
Gerrit is a web based code review system, facilitating online code
|
||||
reviews for projects using the Git version control system.
|
||||
|
||||
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. This functionality enables a more
|
||||
centralized usage of Git.
|
||||
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
Google developed Mondrian, a Perforce based code review tool to
|
||||
facilitate peer-review of changes prior to submission to the central
|
||||
code repository. Mondrian is not open source, as it is tied to the
|
||||
use of Perforce and to many Google-only services, such as Bigtable.
|
||||
Google employees have often described how useful Mondrian and its
|
||||
peer-review process is to their day-to-day work.
|
||||
|
||||
Guido van Rossum open sourced portions of Mondrian within Rietveld,
|
||||
a similar code review tool running on Google App Engine, but for
|
||||
use with Subversion rather than Perforce. Rietveld is in common
|
||||
use by many open source projects, facilitating their peer reviews
|
||||
much as Mondrian does for Google employees. Unlike Mondrian and
|
||||
the Google Perforce triggers, Rietveld is strictly advisory and
|
||||
does not enforce peer-review prior to submission.
|
||||
|
||||
Git is a distributed version control system, wherein each repository
|
||||
is assumed to be owned/maintained by a single user. There are no
|
||||
inherit security controls built into Git, so the ability to read
|
||||
from or write to a repository is controlled entirely by the host's
|
||||
filesystem access controls. When multiple maintainers collaborate
|
||||
on a single shared repository a high degree of trust is required,
|
||||
as any collaborator with write access can alter the repository.
|
||||
|
||||
Gitosis provides tools to secure centralized Git repositories,
|
||||
permitting multiple maintainers to manage the same project at once,
|
||||
by restricting the access to only over a secure network protocol,
|
||||
much like Perforce secures a repository by only permitting access
|
||||
over its network port.
|
||||
|
||||
The Android Open Source Project (AOSP) was founded by Google by the
|
||||
open source releasing of the Android operating system. AOSP has
|
||||
selected Git as its primary version control tool. As many of the
|
||||
engineers have a background of working with Mondrian at Google,
|
||||
there is a strong desire to have the same (or better) feature set
|
||||
available for Git and AOSP.
|
||||
|
||||
Gerrit Code Review started as a simple set of patches to Rietveld,
|
||||
and was originally built to service AOSP. This quickly turned
|
||||
into a fork as we added access control features that Guido van
|
||||
Rossum did not want to see complicating the Rietveld code base. As
|
||||
the functionality and code were starting to become drastically
|
||||
different, a different name was needed. Gerrit calls back to the
|
||||
original namesake of Rietveld, Gerrit Rietveld, a Dutch architect.
|
||||
|
||||
Gerrit 2.x is a complete rewrite of the Gerrit fork, completely
|
||||
changing the implementation from Python on Google App Engine, to Java
|
||||
on a J2EE servlet container and a SQL database.
|
||||
|
||||
* link:http://video.google.com/videoplay?docid=-8502904076440714866[Mondrian Code Review On The Web]
|
||||
* link:http://code.google.com/p/rietveld/[Rietveld - Code Review for Subversion]
|
||||
* link:http://eagain.net/gitweb/?p=gitosis.git;a=blob;f=README.rst;hb=HEAD[Gitosis README]
|
||||
* link:http://source.android.com/[Android Open Source Project]
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Developers create one or more changes on their local desktop system,
|
||||
then upload them for review to Gerrit using the standard `git push`
|
||||
command line program, or any GUI which can invoke `git push` on
|
||||
behalf of the user. Authentication and data transfer are handled
|
||||
through SSH. Users are authenticated by username and public/private
|
||||
key pair, and all data transfer is protected by the SSH connection
|
||||
and Git's own data integrity checks.
|
||||
|
||||
Each Git commit created on the client desktop system is converted
|
||||
into a unique change record which can be reviewed independently.
|
||||
Change records are stored in PostgreSQL, where they can be queried to
|
||||
present customized user dashboards, enumerating any pending changes.
|
||||
|
||||
A summary of each newly uploaded change is automatically emailed
|
||||
to reviewers, so they receive a direct hyperlink to review the
|
||||
change on the web. Reviewer email addresses can be specified on the
|
||||
`git push` command line, but typically reviewers are automatically
|
||||
selected by Gerrit by identifying users who have change approval
|
||||
permissions in the project.
|
||||
|
||||
Reviewers use the web interface to read the side-by-side or unified
|
||||
diff of a change, and insert draft inline comments where appropriate.
|
||||
A draft comment is visible only to the reviewer, until they publish
|
||||
those comments. Published comments are automatically emailed to
|
||||
the change author by Gerrit, and are CC'd to all other reviewers
|
||||
who have already commented on the change.
|
||||
|
||||
When publishing comments reviewers are also given the opportunity
|
||||
to score the change, indicating whether they feel the change is
|
||||
ready for inclusion in the project, needs more work, or should be
|
||||
rejected outright. These scores provide direct feedback to Gerrit's
|
||||
change submit function.
|
||||
|
||||
After a change has been scored positively by reviewers, Gerrit
|
||||
enables a submit button on the web interface. Authorized users
|
||||
can push the submit button to have the change enter the project
|
||||
repository. The equivilant in Subversion or Perforce would be
|
||||
that Gerrit is invoking `svn commit` or `p4 submit` on behalf of
|
||||
the web user pressing the button. Due to the way Git audit trails
|
||||
are maintained, the user pressing the submit button does not need
|
||||
to be the author of the change.
|
||||
|
||||
|
||||
Infrastructure
|
||||
--------------
|
||||
|
||||
End-user web browsers make HTTP requests directly to Gerrit's
|
||||
HTTP server. As nearly all of the user interface is implemented
|
||||
through Google Web Toolkit (GWT), the majority of these requests
|
||||
are transmitting compressed JSON payloads, with all HTML being
|
||||
generated within the browser. Most responses are under 1 KB.
|
||||
|
||||
Gerrit's HTTP server side component is implemented as a standard
|
||||
Java servlet, and thus runs within any J2EE servlet container.
|
||||
Popular choices for deployments would be Tomcat or Jetty, as these
|
||||
are high-quality open-source servlet containers that are readily
|
||||
available for download.
|
||||
|
||||
End-user uploads are performed over SSH, so Gerrit's servlets also
|
||||
start up a background thread to receive SSH connections through
|
||||
an independent SSH port. SSH clients communicate directly with
|
||||
this port, bypassing the HTTP server used by browsers.
|
||||
|
||||
Server side data storage for Gerrit is broken down into two different
|
||||
categories:
|
||||
|
||||
* Git repository data
|
||||
* Gerrit metadata
|
||||
|
||||
The Git repository data is the Git object database used to store
|
||||
already submitted revisions, as well as all uploaded (proposed)
|
||||
changes. Gerrit uses the standard Git repository format, and
|
||||
therefore requires direct filesystem access to the repositories.
|
||||
All repository data is stored in the filesystem and accessed through
|
||||
the JGit library. Repository data can be stored on remote servers
|
||||
accessible through NFS or SMB, but the remote directory must
|
||||
be mounted on the Gerrit server as part of the local filesystem
|
||||
namespace. Remote filesystems are likely to perform worse than
|
||||
local ones, due to Git disk IO behavior not being optimized for
|
||||
remote access.
|
||||
|
||||
The Gerrit metadata contains a summary of the available changes,
|
||||
all comments (published and drafts), and individual user account
|
||||
information. The metadata is housed in a PostgreSQL database,
|
||||
which can be located either on the same server as Gerrit, or on
|
||||
a different (but nearby) server. Most installations would opt to
|
||||
install both Gerrit and PostgreSQL on the same server, to reduce
|
||||
administration overheads.
|
||||
|
||||
User authentication is handled by OpenID, and therefore Gerrit
|
||||
requires that the OpenID provider selected by a user must be
|
||||
online and operating in order to authenticate that user.
|
||||
|
||||
* link:http://code.google.com/webtoolkit/[Google Web Toolkit (GWT)]
|
||||
* link:http://www.kernel.org/pub/software/scm/git/docs/gitrepository-layout.html[Git Repository Format]
|
||||
* link:http://www.postgresql.org/about/[About PostgreSQL]
|
||||
* link:http://openid.net/developers/specs/[OpenID Specifications]
|
||||
|
||||
|
||||
Project Information
|
||||
-------------------
|
||||
|
||||
Gerrit is developed as a self-hosting open source project:
|
||||
|
||||
* link:http://code.google.com/p/gerrit/[Project Homepage]
|
||||
* link:http://code.google.com/p/gerrit/downloads/list[Release Versions]
|
||||
* link:http://code.google.com/p/gerrit/wiki/Source?tm=4[Source]
|
||||
* link:http://code.google.com/p/gerrit/issues/list[Issue Tracking]
|
||||
* link:https://review.source.android.com/[Change Review]
|
||||
|
||||
|
||||
Internationalization and Localization
|
||||
-------------------------------------
|
||||
|
||||
As a source code review system for open source projects, where the
|
||||
commonly preferred language for communication is typically English,
|
||||
Gerrit does not make internationalization or localization a priority.
|
||||
|
||||
The majority of Gerrit's users will be writing change descriptions
|
||||
and comments in English, and therefore an English user interface
|
||||
is usable by the target user base.
|
||||
|
||||
Gerrit uses GWT's i18n support to externalize all constant strings
|
||||
and messages shown to the user, so that in the future someone who
|
||||
really needed a translated version of the UI could contribute new
|
||||
string files for their locale(s).
|
||||
|
||||
Right-to-left (RTL) support is only barely considered within the
|
||||
Gerrit code base. Some portions of the code have tried to take
|
||||
RTL into consideration, while others probably need to be modified
|
||||
before translating the UI to an RTL language.
|
||||
|
||||
* link:i18n-readme.html[Gerrit's i18n Support]
|
||||
|
||||
|
||||
Accessibility Considerations
|
||||
----------------------------
|
||||
|
||||
Whenever possible Gerrit displays raw text rather than image icons,
|
||||
so screen readers should still be able to provide useful information
|
||||
to blind persons accessing Gerrit sites.
|
||||
|
||||
Standard HTML hyperlinks are used rather than HTML div or span tags
|
||||
with click listeners. This provides two benefits to the end-user.
|
||||
The first benefit is that screen readers are optimized to locating
|
||||
standard hyperlink anchors and presenting them to the end-user as
|
||||
a navigation action. The second benefit is that users can use
|
||||
the 'open in new tab/window' feature of their browser whenever
|
||||
they choose.
|
||||
|
||||
When possible, Gerrit uses the ARIA properties on DOM widgets to
|
||||
provide hints to screen readers.
|
||||
|
||||
|
||||
Browser Compatibility
|
||||
---------------------
|
||||
|
||||
Supporting non-JavaScript enabled browsers is a non-goal for Gerrit.
|
||||
|
||||
As Gerrit is a pure-GWT application with no server side rendering
|
||||
fallbacks, the browser must support modern JavaScript semantics in
|
||||
order to access the Gerrit web application. Dumb clients such as
|
||||
`lynx`, `wget`, `curl`, or even many search engine spiders are not
|
||||
able to access Gerrit content.
|
||||
|
||||
As Google Web Toolkit (GWT) is used to generate the browser
|
||||
specific versions of the client-side JavaScript code, Gerrit works
|
||||
on any JavaScript enabled browser which GWT can produce code for.
|
||||
This covers the majority of the popular browsers.
|
||||
|
||||
The Gerrit project does not have the development resources necessary
|
||||
to support two parallel UI implementations (GWT based JavaScript
|
||||
and server-side rendering). Consequently only one is implemented.
|
||||
|
||||
There are number of web browsers available with full JavaScript
|
||||
support, and nearly every operating system (including any PDA-like
|
||||
mobile phone) comes with one standard. Users who are committed
|
||||
to developing changes for a Gerrit managed project can be expected
|
||||
to be able to run a JavaScript enabled browser, as they also would
|
||||
need to be running Git in order to contribute.
|
||||
|
||||
There are a number of open source browsers available, including
|
||||
Firefox and Chromium. Users have some degree of choice in their
|
||||
browser selection, including being able to build and audit their
|
||||
browser from source.
|
||||
|
||||
The majority of the content stored within Gerrit is also available
|
||||
through other means, such as gitweb or the `git://` protocol.
|
||||
Any existing search engine spider can crawl the server-side HTML
|
||||
produced by gitweb, and thus can index the majority of the changes
|
||||
which might appear in Gerrit. Some engines may even choose to
|
||||
crawl the native version control database, such as ohloh.net does.
|
||||
Therefore the lack of support for most search engine spiders is a
|
||||
non-issue for most Gerrit deployments.
|
||||
|
||||
|
||||
Product Integration
|
||||
-------------------
|
||||
|
||||
Gerrit integrates with an existing gitweb installation by optionally
|
||||
creating hyperlinks to reference changes on the gitweb server.
|
||||
|
||||
Gerrit integrates with an existing git-daemon installation by
|
||||
optionally displaying `git://` URLs for users to download a
|
||||
change through the native Git protocol.
|
||||
|
||||
Gerrit integrates with any OpenID provider for user authentication,
|
||||
making it easier for users to join a Gerrit site and manage their
|
||||
authentication credentials to it. To make use of Google Accounts
|
||||
as an OpenID provider easier, Gerrit has a shorthand "Sign in with
|
||||
a Google Account" link on its sign-in screen. Gerrit also supports
|
||||
a shorthand sign in link for Yahoo!. Other providers may also be
|
||||
supported more directly in the future.
|
||||
|
||||
Site administrators may limit the range of OpenID providers to
|
||||
a subset of "reliable providers". Users may continue to use
|
||||
any OpenID provider to publish comments, but granted privileges
|
||||
are only available to a user if the only entry point to their
|
||||
account is through the defined set of "reliable OpenID providers".
|
||||
This permits site administrators to require HTTPS for OpenID,
|
||||
and to use only large main-stream providers that are trustworthy,
|
||||
or to require users to only use a custom OpenID provider installed
|
||||
alongside Gerrit Code Review.
|
||||
|
||||
Gerrit integrates with some types of corporate single-sign-on (SSO)
|
||||
solutions, typically by having the SSO authentication be performed
|
||||
in a reverse proxy web server and then blindly trusting that all
|
||||
incoming connections have been authenticated by that reverse proxy.
|
||||
When configured to use this form of authentication, Gerrit does
|
||||
not integrate with OpenID providers.
|
||||
|
||||
When installing Gerrit, administrators may optionally include an
|
||||
HTML header or footer snippet which may include user tracking code,
|
||||
such as that used by Google Analytics. This is a per-instance
|
||||
configuration that must be done by hand, and is not supported
|
||||
out of the box. Other site trackers instead of Google Analytics
|
||||
can be used, as the administrator can supply any HTML/JavaScript
|
||||
they choose.
|
||||
|
||||
Gerrit does not integrate with any Google service, or any other
|
||||
services other than those listed above.
|
||||
|
||||
|
||||
Standards / Developer APIs
|
||||
--------------------------
|
||||
|
||||
Gerrit uses an XSRF protected variant of JSON-RPC 1.1 to communicate
|
||||
between the browser client and the server.
|
||||
|
||||
As the protocol is not the GWT-RPC protocol, but is instead a
|
||||
self-describing standard JSON format it is easily implemented by
|
||||
any 3rd party client application, provided the client has a JSON
|
||||
parser and HTTP client library available.
|
||||
|
||||
As the entire command set necessary for the standard web browser
|
||||
based UI is exposed through JSON-RPC over HTTP, there are no other
|
||||
data feeds or command interfaces to the server.
|
||||
|
||||
Commands requiring user authentication may require the user agent to
|
||||
complete a sign-in cycle through the user's OpenID provider in order
|
||||
to establish the HTTP cookie Gerrit uses to track user identity.
|
||||
Automating this sign-in process for non-web browser agents is
|
||||
outside of the scope of Gerrit, as each OpenID provider uses its own
|
||||
sign-in sequence. Use of OpenID providers which have difficult to
|
||||
automate interfaces may make it impossible for non-browser agents
|
||||
to be used with the JSON-RPC interface.
|
||||
|
||||
* link:http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html[JSON-RPC 1.1]
|
||||
* link:http://android.git.kernel.org/?p=tools/gwtjsonrpc.git;a=blob;f=README;hb=HEAD[XSRF JSON-RPC]
|
||||
|
||||
|
||||
Privacy Considerations
|
||||
----------------------
|
||||
|
||||
Gerrit stores the following information per user account:
|
||||
|
||||
* Full Name
|
||||
* Preferred Email Address
|
||||
* Mailing Address '(Optional, Encrypted)'
|
||||
* Country '(Optional, Encrypted)'
|
||||
* Phone Number '(Optional, Encrypted)'
|
||||
* Fax Number '(Optional, Encrypted)'
|
||||
|
||||
The full name and preferred email address fields are shown to any
|
||||
site visitor viewing a page containing a change uploaded by the
|
||||
account owner, or containing a published comment written by the
|
||||
account owner.
|
||||
|
||||
Showing the full name and preferred email is approximately the same
|
||||
risk as the `From` header of an email posted to a public mailing
|
||||
list that maintains archives, and Gerrit treats these fields in
|
||||
much the same way that a mailing list archive might handle them.
|
||||
Users who don't want to expose this information should either not
|
||||
participate in a Gerrit based online community, or open a new email
|
||||
address dedicated for this use.
|
||||
|
||||
As the Gerrit UI data is only available through XSRF protected
|
||||
JSON-RPC calls, "screen-scraping" for email addresses is difficult,
|
||||
but not impossible. It is unlikely a spammer will go through the
|
||||
effort required to code a custom scraping application necessary
|
||||
to cull email addresses from published Gerrit comments. In most
|
||||
cases these same addresses would be more easily obtained from the
|
||||
project's mailing list archives.
|
||||
|
||||
The user's name and email address is stored unencrypted in the
|
||||
Gerrit metadata store, typically a PostgreSQL database.
|
||||
|
||||
The snail-mail mailing address, country, and phone and fax numbers
|
||||
are gathered to help project leads contact the user should there
|
||||
be a legal question regarding any change they have uploaded.
|
||||
|
||||
These sensitive fields are immediately encrypted upon receipt with
|
||||
a GnuPG public key, and stored "off site" in another data store,
|
||||
isolated from the main Gerrit change data. Gerrit does not have
|
||||
access to the matching private key, and as such cannot decrypt the
|
||||
information. Therefore these fields are write-once in Gerrit, as not
|
||||
even the account owner can recover the values they previously stored.
|
||||
|
||||
It is expected that the address information would only need to be
|
||||
decrypted and revealed with a valid court subpoena, but this is
|
||||
really left to the discretion of the Gerrit site administrator as
|
||||
to when it is reasonable to reveal this information to a 3rd party.
|
||||
|
||||
|
||||
Spam and Abuse Considerations
|
||||
-----------------------------
|
||||
|
||||
Gerrit makes no attempt to detect spam changes or comments. The
|
||||
somewhat high barrier to entry makes it unlikely that a spammer
|
||||
will target Gerrit.
|
||||
|
||||
To upload a change, the client must speak the native Git protocol
|
||||
embedded in SSH, with some custom Gerrit semantics added on top.
|
||||
The client must have their public key already stored in the Gerrit
|
||||
database, which can only be done through the XSRF protected
|
||||
JSON-RPC interface. The level of effort required to construct
|
||||
the necessary tools to upload a well-formatted change that isn't
|
||||
rejected outright by the Git and Gerrit checksum validations is
|
||||
too high to for a spammer to get any meaningful return.
|
||||
|
||||
To post and publish a comment a client must sign in with an OpenID
|
||||
provider and then use the XSRF protected JSON-RPC interface to
|
||||
publish the draft on an existing change record. Again, the level of
|
||||
effort required to implement the Gerrit specific XSRF protections
|
||||
and the JSON-RPC payload format necessary to post a draft and then
|
||||
publish that draft is simply too high for a spammer to bother with.
|
||||
|
||||
Both of these assumptions are also based upon the idea that Gerrit
|
||||
will be a lot less popular than blog software, and thus will be
|
||||
running on a lot less websites. Spammers therefore have very little
|
||||
returned benefit for getting over the protocol hurdles.
|
||||
|
||||
These assumptions may need to be revisited in the future if any
|
||||
public Gerrit site actually notices spam.
|
||||
|
||||
|
||||
Latency
|
||||
-------
|
||||
|
||||
Gerrit targets for sub-250 ms per page request, mostly by using
|
||||
very compact JSON payloads bewteen client and server. However, as
|
||||
most of the serving stack (network, hardware, PostgreSQL metadata
|
||||
database) is out of control of the Gerrit developers, no real
|
||||
guarantees can be made about latency.
|
||||
|
||||
|
||||
Scalability
|
||||
-----------
|
||||
|
||||
Gerrit is designed for a very large scale open source project, or
|
||||
large commerical development project. Roughly this amounts to
|
||||
parameters such as the following:
|
||||
|
||||
.Design Parameters
|
||||
[options="header"]
|
||||
|======================================================
|
||||
|Parameter | Default Maximum | Estimated Maximum
|
||||
|Projects | 1,000 | 10,000
|
||||
|Contributors | 1,000 | 50,000
|
||||
|Changes/Day | 100 | 2,000
|
||||
|Revisions/Change | 20 | 20
|
||||
|Files/Change | 50 | 16,000
|
||||
|Comments/File | 100 | 100
|
||||
|Reviewers/Change | 8 | 8
|
||||
|======================================================
|
||||
|
||||
Out of the box, Gerrit will handle the "Default Maximum". Site
|
||||
administrators may reconfigure their servers by editing gerrit.config
|
||||
to run closer to the estimated maximum if sufficient memory is made
|
||||
avaliable to the JVM and the relevant cache.*.memoryLimit variables
|
||||
are increased from their defaults.
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Very few, if any open source projects have more than a handful of
|
||||
Git repositories associated with them. Since Gerrit treats each
|
||||
Git repository as a project, an upper limit of 10,000 projects
|
||||
is reasonable. If a site has more than 1,000 projects, administrators
|
||||
should increase
|
||||
link:config-gerrit.html#cache.name.memoryLimit[`cache.projects.memoryLimit`]
|
||||
to match.
|
||||
|
||||
Almost no open source project has 1,000 contributors over all time,
|
||||
let alone on a daily basis. This default figure of 1,000 was WAG'd by
|
||||
looking at PR statements published by cell phone companies picking
|
||||
up the Android operating system. If all of the stated employees in
|
||||
those PR statements were working on *only* the open source Android
|
||||
repositories, we might reach the 1,000 estimate listed here. Knowing
|
||||
these companies as being very closed-source minded in the past, it
|
||||
is very unlikely all of their Android engineers will be working on
|
||||
the open source repository, and thus 1,000 is a very high estimate.
|
||||
|
||||
The upper maximum of 50,000 contributors is based on existing
|
||||
installations that are already handling quite a bit more than the
|
||||
default maximum of 1,000 contributors. Given how the user data is
|
||||
stored and indexed, supporting 50,000 contributor accounts (or more)
|
||||
is easily possible for a server. If a server has more than 1,000
|
||||
*active* contributors,
|
||||
link:config-gerrit.html#cache.name.memoryLimit[`cache.accounts.memoryLimit`]
|
||||
should be increased by the site administrator, if sufficient RAM
|
||||
is available to the host JVM.
|
||||
|
||||
The estimate of 100 changes per day was WAG'd off some estimates
|
||||
originally obtained from Android's development history. Writing a
|
||||
good change that will be accepted through a peer-review process
|
||||
takes time. The average engineer may need 4-6 hours per change just
|
||||
to write the code and unit tests. Proper design consideration and
|
||||
additional but equally important tasks such as meetings, interviews,
|
||||
training, and eating lunch will often pad the engineer's day out
|
||||
such that suitable changes are only posted once a day, or once
|
||||
every other day. For reference, the entire Linux kernel has an
|
||||
average of only 79 changes/day. If more than 100 changes are active
|
||||
per day, site administrators should consider increasing the
|
||||
link:config-gerrit.html#cache.name.memoryLimit[`cache.diff.memoryLimit`]
|
||||
and `cache.diff_intraline.memoryLimit`.
|
||||
|
||||
On average any given change will need to be modified once to address
|
||||
peer review comments before the final revision can be accepted by the
|
||||
project. Executing these revisions also eats into the contributor's
|
||||
time, and is another factor limiting the number of changes/day
|
||||
accepted by the Gerrit instance. However, even though this implies
|
||||
only 2 revisions/change, many existing Gerrit installations have seen
|
||||
20 or more revisions/change, when new contributors are learning the
|
||||
project's style and conventions.
|
||||
|
||||
On average, each change will have 2 reviewers, a human and an
|
||||
automated test bed system. Usually this would be the project lead, or
|
||||
someone who is familiar with the code being modified. The time
|
||||
required to comment further reduces the time available for writing
|
||||
one's own changes. However, existing Gerrit installations have seen 8
|
||||
or more reviewers frequently show up on changes that impact many
|
||||
functional areas, and therefore it is reasonable to expect 8 or more
|
||||
reviewers to be able to work together on a single change.
|
||||
|
||||
Existing installations have successfully processed change reviews with
|
||||
more than 16,000 files per change. However, since 16,000 modified/new
|
||||
files is a massive amount of code to review, it is more typical to see
|
||||
less than 10 files modified in any single change. Changes larger than
|
||||
10 files are typically merges, for example integrating the latest
|
||||
version of an upstream library, where the reviewer has little to do
|
||||
beyond verifying the project compiles and passes a test suite.
|
||||
|
||||
CPU Usage - Web UI
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Gerrit's web UI would require on average `4+F+F*C` HTTP requests to
|
||||
review a change and post comments. Here `F` is the number of files
|
||||
modified by the change, and `C` is the number of inline comments left
|
||||
by the reviewer per file. The constant 4 accounts for the request
|
||||
to load the reviewer's dashboard, to load the change detail page,
|
||||
to publish the review comments, and to reload the change detail
|
||||
page after comments are published.
|
||||
|
||||
This WAG'd estimate boils down to 216,000 HTTP requests per day
|
||||
(QPD). Assuming these are evenly distributed over an 8 hour work day
|
||||
in a single time zone, we are looking at approximately 7.5 queries
|
||||
per second (QPS).
|
||||
|
||||
----
|
||||
QPD = Changes_Day * Revisions_Change * Reviewers_Change * (4 + F + F * C)
|
||||
= 2,000 * 2 * 1 * (4 + 10 + 10 * 4)
|
||||
= 216,000
|
||||
QPS = QPD / 8_Hours / 60_Minutes / 60_Seconds
|
||||
= 7.5
|
||||
----
|
||||
|
||||
Gerrit serves most requests in under 60 ms when using the loopback
|
||||
interface and a single processor. On a single CPU system there is
|
||||
sufficient capacity for 16 QPS. A dual processor system should be
|
||||
more than sufficient for a site with the estimated load described above.
|
||||
|
||||
Given a more realistic estimate of 79 changes per day (from the
|
||||
Linux kernel) suggests only 8,532 queries per day, and a much lower
|
||||
0.29 QPS when spread out over an 8 hour work day.
|
||||
|
||||
CPU Usage - Git over SSH/HTTP
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A 24 core server is able to handle ~25 concurrent `git fetch`
|
||||
operations per second. The issue here is each concurrent operation
|
||||
demands one full core, as the computation is almost entirely server
|
||||
side CPU bound. 25 concurrent operations is known to be sufficient to
|
||||
support hundreds of active developers and 50 automated build servers
|
||||
polling for updates and building every change. (This data was derived
|
||||
from an actual installation's performance.)
|
||||
|
||||
Because of the distributed nature of Git, end-users don't need to
|
||||
contact the central Gerrit Code Review server very often. For `git
|
||||
fetch` traffic, link:pgm-daemon.html[slave mode] is known to be an
|
||||
effective way to offload traffic from the main server, permitting it
|
||||
to scale to a large user base without needing an excessive number of
|
||||
cores in a single system.
|
||||
|
||||
Clients on very slow network connections (for example home office
|
||||
users on VPN over home DSL) may be network bound rather than server
|
||||
side CPU bound, in which case a core may be effectively shared with
|
||||
another user. Possible core sharing due to network bottlenecks
|
||||
generally holds true for network connections running below 10 MiB/sec.
|
||||
|
||||
If the server's own network interface is 1 Gib/sec (Gigabit Ethernet),
|
||||
the system can really only serve about 10 concurrent clients at the
|
||||
10 MiB/sec speed, no matter how many cores it has.
|
||||
|
||||
Disk Usage
|
||||
~~~~~~~~~~
|
||||
|
||||
The average size of a revision in the Linux kernel once compressed by
|
||||
Git is 2,327 bytes, or roughly 2 KiB. Over the course of a year a
|
||||
Gerrit server running with the estimated maxium parameters above might
|
||||
see an introduction of 1.4 GiB over the total set of 10,000 projects
|
||||
hosted in that server. This figure assumes the majority of the content
|
||||
is human written source code, and not large binary blobs such as disk
|
||||
images or media files.
|
||||
|
||||
Production Gerrit installations have been tested, and are known to
|
||||
handle Git repositories in the multigigabyte range, storing binary
|
||||
files, ranging in size from a few kilobytes (for example compressed
|
||||
icons) to 800+ megabytes (firmware images, large uncompressed original
|
||||
artwork files). Best practices encourage breaking very large binary
|
||||
files into their Git repositories based on access, to prevent desktop
|
||||
clients from needing to clone unnecessary materials (for example a C
|
||||
developer does not need every 800+ megabyte firmware image created by
|
||||
the product's quality assurance team).
|
||||
|
||||
Redundancy & Reliability
|
||||
------------------------
|
||||
|
||||
Gerrit largely assumes that the local filesystem where Git repository
|
||||
data is stored is always available. Important data written to disk
|
||||
is also forced to the platter with an `fsync()` once it has been
|
||||
fully written. If the local filesystem fails to respond to reads
|
||||
or becomes corrupt, Gerrit has no provisions to fallback or retry
|
||||
and errors will be returned to clients.
|
||||
|
||||
Gerrit largely assumes that the metadata PostgreSQL database is
|
||||
online and answering both read and write queries. Query failures
|
||||
immediately result in the operation aborting and errors being
|
||||
returned to the client, with no retry or fallback provisions.
|
||||
|
||||
Due to the relatively small scale described above, it is very likely
|
||||
that the Git filesystem and PostgreSQL based metadata database
|
||||
are all housed on the same server that is running Gerrit. If any
|
||||
failure arises in one of these components, it is likely to manifest
|
||||
in the others too. It is also likely that the administrator cannot
|
||||
be bothered to deploy a cluster of load-balanced server hardware,
|
||||
as the scale and expected load does not justify the hardware or
|
||||
management costs.
|
||||
|
||||
Most deployments caring about reliability will setup a warm-spare
|
||||
standby system and use a manual fail-over process to switch from the
|
||||
failed system to the warm-spare.
|
||||
|
||||
As Git is a distributed version control system, and open source
|
||||
projects tend to have contributors from all over the world, most
|
||||
contributors will be able to tolerate a Gerrit down time of several
|
||||
hours while the administrator is notified, signs on, and brings the
|
||||
warm-spare up. Pending changes are likely to need at least 24 hours
|
||||
of time on the Gerrit site anyway in order to ensure any interested
|
||||
parties around the world have had a chance to comment. This expected
|
||||
lag largely allows for some downtime in a disaster scenario.
|
||||
|
||||
Backups
|
||||
~~~~~~~
|
||||
|
||||
PostgreSQL can be configured to save its write-ahead-log (WAL)
|
||||
and ship these logs to other systems, where they are applied to
|
||||
a warm-standby backup in real time. Gerrit instances which care
|
||||
about reduduncy will setup this feature of PostgreSQL to ensure
|
||||
the warm-standby is reasonably current should the master go offline.
|
||||
|
||||
Gerrit can be configured to replicate changes made to the local
|
||||
Git repositories over any standard Git transports. This can be
|
||||
configured in `'$site_path'/etc/replication.conf` to send copies
|
||||
of all changes over SSH to other servers, or to the Amazon S3 blob
|
||||
storage service.
|
||||
|
||||
|
||||
Logging Plan
|
||||
------------
|
||||
|
||||
Gerrit does not maintain logs on its own.
|
||||
|
||||
Published comments contain a publication date, so users can judge
|
||||
when the comment was posted and decide if it was "recent" or not.
|
||||
Only the timestamp is stored in the database, the IP address of
|
||||
the comment author is not stored.
|
||||
|
||||
Changes uploaded over the SSH daemon from `git push` have the
|
||||
standard Git reflog updated with the date and time that the upload
|
||||
occurred, and the Gerrit account identity of who did the upload.
|
||||
Changes submitted and merged into a branch also update the
|
||||
Git reflog. These logs are available only to the Gerrit site
|
||||
administrator, and they are not replicated through the automatic
|
||||
replication noted earlier. These logs are primarly recorded for an
|
||||
"oh s**t" moment where the administrator has to rewind data. In most
|
||||
installations they are a waste of disk space. Future versions of
|
||||
JGit may allow disabling these logs, and Gerrit may take advantage
|
||||
of that feature to stop writing these logs.
|
||||
|
||||
A web server positioned in front of Gerrit (such as a reverse proxy)
|
||||
or the hosting servlet container may record access logs, and these
|
||||
logs may be mined for usage information. This is outside of the
|
||||
scope of Gerrit.
|
||||
|
||||
|
||||
Testing Plan
|
||||
------------
|
||||
|
||||
Gerrit is currently manually tested through its web UI.
|
||||
|
||||
JGit has a fairly extensive automated unit test suite. Most new
|
||||
changes to JGit are rejected unless corresponding automated unit
|
||||
tests are included.
|
||||
|
||||
|
||||
Caveats
|
||||
-------
|
||||
|
||||
Reitveld can't be used as it does not provide the "submit over the
|
||||
web" feature that Gerrit provides for Git.
|
||||
|
||||
Gitosis can't be used as it does not provide any code review
|
||||
features, but it does provide basic access controls.
|
||||
|
||||
Email based code review does not scale to a project as large and
|
||||
complex as Android. Most contributors at least need some sort of
|
||||
dashboard to keep track of any pending reviews, and some way to
|
||||
correlate updated revisions back to the comments written on prior
|
||||
revisions of the same logical change.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,98 +0,0 @@
|
|||
Gerrit Code Review - Eclipse Setup
|
||||
==================================
|
||||
|
||||
This document is about configuring Gerrit Code Review into an
|
||||
Eclipse workspace for development and debugging with GWT.
|
||||
|
||||
Java 6 or later SDK is also required to run GWT's compiler and
|
||||
runtime debugging environment.
|
||||
|
||||
|
||||
Maven Plugin
|
||||
------------
|
||||
|
||||
Install the Maven Integration plugins:
|
||||
|
||||
http://m2eclipse.codehaus.org/[m2eclipse]
|
||||
|
||||
|
||||
Code Formatter Settings
|
||||
-----------------------
|
||||
|
||||
Import `tools/GoogleFormat.xml` using Window -> Preferences ->
|
||||
Java -> Code Style -> Formatter -> Import...
|
||||
|
||||
This will define the 'Google Format' profile, which the project
|
||||
settings prefer when formatting source code.
|
||||
|
||||
|
||||
Import Projects
|
||||
---------------
|
||||
|
||||
Import the projects into Eclipse by going to File -> Import... -> Maven ->
|
||||
Existing Maven Projects and selecting the directory containing pom.xml.
|
||||
|
||||
Some of the source code is generated with ANTLR sources. To build
|
||||
these files, right click on the imported projects, Maven -> Update
|
||||
Project Configuration. This will resolve compile errors identified
|
||||
after import.
|
||||
|
||||
|
||||
Site Initialization
|
||||
-------------------
|
||||
|
||||
link:dev-readme.html#build[Build] once on the command line and
|
||||
then follow link:dev-readme.html#init[Site Initialization] in the
|
||||
Developer Setup guide to configure a local site for testing.
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Running the Daemon
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Duplicate the existing `pgm_daemon` launch configuration:
|
||||
|
||||
* Run -> Debug Configurations ...
|
||||
* Java Application -> `pgm_daemon`
|
||||
* Right click, Duplicate
|
||||
|
||||
* Modify the name to be unique.
|
||||
|
||||
* Switch to Arguments tab.
|
||||
* Edit the `-d` program argument flag to match the path used during
|
||||
'init'. The template launch configuration resolves to ../test_site
|
||||
since that is what the documentation recommends.
|
||||
|
||||
* Switch to Common tab.
|
||||
* Change Save as to be Local file.
|
||||
|
||||
|
||||
Running Hosted Mode
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Import the gerrit-gwtdebug project:
|
||||
|
||||
* Import gerrit-gwtdebug/pom.xml using General -> Maven Projects
|
||||
|
||||
Duplicate the existing `gwtui_dbg` launch configuration:
|
||||
|
||||
* Run -> Debug Configurations ...
|
||||
* Java Application -> `gwtui_dbg`
|
||||
* Right click, Duplicate
|
||||
|
||||
* Modify the name to be unique.
|
||||
|
||||
* Switch to Arguments tab.
|
||||
* Edit the `-Dgerrit.site_path=` VM argument to match the path
|
||||
used during 'init'. The template launch configuration resolves
|
||||
to ../test_site since that is what the documentation recommends.
|
||||
|
||||
* Switch to Common tab.
|
||||
* Change Save as to be Local file.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,192 +0,0 @@
|
|||
Gerrit Code Review - Developer Setup
|
||||
====================================
|
||||
|
||||
Apache Maven is needed to compile the code, and a SQL database
|
||||
to house the review metadata. H2 is recommended for development
|
||||
databases, as it requires no external server process.
|
||||
|
||||
Get the Source
|
||||
--------------
|
||||
|
||||
Create a new client workspace:
|
||||
|
||||
----
|
||||
git clone git://android.git.kernel.org/tools/gerrit.git
|
||||
cd gerrit
|
||||
----
|
||||
|
||||
|
||||
Configuring Eclipse
|
||||
-------------------
|
||||
|
||||
To use the Eclipse IDE for development, please see
|
||||
link:dev-eclipse.html[Eclipse Setup] for more details on how to
|
||||
configure the workspace with the Maven build scripts.
|
||||
|
||||
|
||||
[[build]]
|
||||
Building
|
||||
--------
|
||||
|
||||
From the command line:
|
||||
|
||||
----
|
||||
mvn package
|
||||
----
|
||||
|
||||
Output executable WAR will be placed in:
|
||||
|
||||
----
|
||||
gerrit-war/target/gerrit-*.war
|
||||
----
|
||||
|
||||
Mac OS X
|
||||
~~~~~~~~
|
||||
On Mac OS X ensure "Java For Mac OS X 10.5 Upate 4" (or later) has
|
||||
been installed, and that `JAVA_HOME` is set to
|
||||
"/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home".
|
||||
Check the installed version by running `java -version` and looking
|
||||
for 'build 1.6.0_13-b03-211'. Versions of Java 6 prior to this
|
||||
version crash during the build due to a bug in the JIT compiler.
|
||||
|
||||
|
||||
[[init]]
|
||||
Site Initialization
|
||||
-------------------
|
||||
|
||||
After compiling (above), run Gerrit's 'init' command to create a
|
||||
testing site for development use:
|
||||
|
||||
----
|
||||
java -jar gerrit-war/target/gerrit-*.war init -d ../test_site
|
||||
----
|
||||
|
||||
Accept defaults by pressing Enter until 'init' completes, or add
|
||||
the '\--batch' command line option to avoid them entirely. It is
|
||||
recommended to change the listen addresses from '*' to 'localhost' to
|
||||
prevent outside connections from contacting the development instance.
|
||||
|
||||
The daemon will automatically start in the background and a web
|
||||
browser will launch to the start page, enabling login via OpenID.
|
||||
|
||||
Shutdown the daemon after registering the administrator account
|
||||
through the web interface:
|
||||
|
||||
----
|
||||
../test_site/bin/gerrit.sh stop
|
||||
----
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Running the Daemon
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The daemon can be directly launched from the build area, without
|
||||
copying to the test site:
|
||||
|
||||
----
|
||||
java -jar gerrit-war/target/gerrit-*.war daemon -d ../test_site
|
||||
----
|
||||
|
||||
|
||||
Querying the Database
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The embedded H2 database can be queried and updated from the
|
||||
command line. If the daemon is not currently running:
|
||||
|
||||
----
|
||||
java -jar gerrit-war/target/gerrit-*.war gsql -d ../test_site
|
||||
----
|
||||
|
||||
Or, if it is running and the database is in use, connect over SSH
|
||||
using an administrator user account:
|
||||
|
||||
----
|
||||
ssh -p 29418 user@localhost gerrit gsql
|
||||
----
|
||||
|
||||
|
||||
Debugging JavaScript
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When debugging browser specific issues use `-Dgwt.style=DETAILED`
|
||||
so the resulting JavaScript more closely matches the Java sources.
|
||||
This can be used to help narrow down what code line 30,400 in the
|
||||
JavaScript happens to be.
|
||||
|
||||
----
|
||||
mvn package -Dgwt.style=DETAILED
|
||||
----
|
||||
|
||||
|
||||
Release Builds
|
||||
--------------
|
||||
|
||||
To create a release build for a production server, or deployment
|
||||
through the download site:
|
||||
|
||||
----
|
||||
./tools/release.sh
|
||||
----
|
||||
|
||||
If AsciiDoc isn't installed or is otherwise unavailable, the WAR
|
||||
can still be built without the embedded documentation by passing
|
||||
an additional flag:
|
||||
|
||||
----
|
||||
./tools/release.sh --without-documentation
|
||||
----
|
||||
|
||||
|
||||
Client-Server RPC
|
||||
-----------------
|
||||
|
||||
The client-server RPC implementation is gwtjsonrpc, not the stock RPC
|
||||
system that comes with GWT. This buys us automatic XSRF protection.
|
||||
It also makes all of the messages readable and writable by any JSON
|
||||
implementation, facilitating "mashups" and 3rd party clients.
|
||||
|
||||
The programming API is virtually identical, except service interfaces
|
||||
extend RemoteJsonService instead of RemoteService.
|
||||
|
||||
|
||||
Why GWT?
|
||||
--------
|
||||
|
||||
We like it. Plus we can write Java code once and run it both in
|
||||
the browser and on the server side.
|
||||
|
||||
|
||||
External Links
|
||||
--------------
|
||||
|
||||
Google Web Toolkit:
|
||||
|
||||
* http://code.google.com/webtoolkit/download.html[Download]
|
||||
|
||||
Apache Maven:
|
||||
|
||||
* http://maven.apache.org/download.html[Download]
|
||||
* http://maven.apache.org/run-maven/index.html[Running]
|
||||
|
||||
Apache SSHD:
|
||||
|
||||
* http://mina.apache.org/sshd/[SSHD]
|
||||
|
||||
H2:
|
||||
|
||||
* http://www.h2database.com/[H2]
|
||||
* http://www.h2database.com/html/grammar.html[SQL Reference]
|
||||
|
||||
PostgreSQL:
|
||||
|
||||
* http://www.postgresql.org/download/[Download]
|
||||
* http://www.postgresql.org/docs/[Documentation]
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
branch ... not found
|
||||
====================
|
||||
|
||||
With this error message Gerrit rejects to push a commit for code
|
||||
review if the specified target branch does not exist.
|
||||
|
||||
To push a change for code review the commit has to be pushed to the
|
||||
project's magical `refs/for/'branch'` ref (for details have a look at
|
||||
link:user-upload.html#push_create[Create Changes]).
|
||||
If you specify a non existing branch in the `refs/for/'branch'` ref
|
||||
the push is failing with the error message 'branch ... not found'.
|
||||
|
||||
To fix this problem verify
|
||||
|
||||
* that the branch name in the push specification is typed correctly
|
||||
(case sensitive) and
|
||||
* that the branch really exists for this project (in the Gerrit WebUI
|
||||
go to 'Admin' -> 'Projects' and browse your project, then click on
|
||||
'Branches' to see all existing branches).
|
||||
|
||||
If it was your intention to create a new branch you can either
|
||||
|
||||
* bypass code review on push as explained link:user-upload.html#bypass_review[here] or
|
||||
* create the new branch in the Gerrit WebUI before pushing (go to
|
||||
'Admin' -> 'Projects' and browse your project, in the 'Branches'
|
||||
tab you can then create a new branch).
|
||||
|
||||
Please note that you need the access right '+2 Create Branch' in the
|
||||
link:access-control.html#category_pHD['Push Branch'] category to create new branches.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
change ... closed
|
||||
=================
|
||||
|
||||
With this error message Gerrit rejects to push a commit to a change
|
||||
that is already closed.
|
||||
|
||||
This error occurs if you are trying to push a commit that contains
|
||||
the Change-Id of a closed change in its commit message. A change can
|
||||
be closed either because it was already submitted and merged or
|
||||
because it was abandoned.
|
||||
|
||||
If the change for which you wanted to upload a new patch set was
|
||||
already submitted and merged you may want to push your commit as a
|
||||
new change. To do this you have to remove the Change-Id from the
|
||||
commit message as explained link:error-push-fails-due-to-commit-message.html[here] and ideally generate a new Change-Id
|
||||
using the link:cmd-hook-commit-msg.html[commit hook] or EGit. Before pushing again it is also
|
||||
recommendable to do a link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[git rebase] to base your commit on the submitted
|
||||
change. Pushing again should now create a new change in Gerrit.
|
||||
|
||||
If the change for which you wanted to upload a new patch set was
|
||||
abandoned and your new changes overcome the reasons for abandoning
|
||||
this change you may want to restore the change in the Gerrit WebUI
|
||||
(browse the abandoned change in the Gerrit WebUI and click on the
|
||||
'Restore Change' button). Afterwards the push should succeed and a
|
||||
new patch set for this change will be created.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
change ... does not belong to project ...
|
||||
=========================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit to a change
|
||||
that belongs to another project.
|
||||
|
||||
This error message means that the user explicitly pushed a commit to
|
||||
a change that belongs to another project by specifying it as target
|
||||
ref. This way of adding a new patch set to a change is deprecated as
|
||||
explained link:user-upload.html#manual_replacement_mapping[here]. It is recommended to only rely on Change-ID's for
|
||||
link:user-upload.html#push_replace[replacing changes].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
change ... not found
|
||||
====================
|
||||
|
||||
With this error message Gerrit rejects to push a commit to a change
|
||||
that cannot be found.
|
||||
|
||||
This error message means that the user explicitly pushed a commit to
|
||||
a non-existing change by specifying it as target ref. This way of
|
||||
adding a new patch set to a change is deprecated as explained link:user-upload.html#manual_replacement_mapping[here].
|
||||
It is recommended to only rely on Change-ID's for link:user-upload.html#push_replace[replacing changes].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
One or more refs/for/ names blocks change upload
|
||||
================================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit for code
|
||||
review if the remote git repository has a branch under the
|
||||
'refs/for/' namespace.
|
||||
|
||||
Gerrit uses the 'refs/for/' namespace for magical refs that represent
|
||||
the review queues for branches in the git repository hosted by
|
||||
Gerrit. If, for a project, a real branch is created under the
|
||||
'refs/for' namespace this conflicts with the namespace reserved for
|
||||
the Gerrit review queues and Gerrit can't accept further pushes for
|
||||
code review.
|
||||
|
||||
To solve this problem all real branches that exist under the
|
||||
'refs/for/' namespace have to be deleted or renamed in the remote git
|
||||
repository.
|
||||
|
||||
To see which branches exist under the 'refs/for/' namespace a Gerrit
|
||||
administrator can run the following command:
|
||||
|
||||
----
|
||||
$ git for-each-ref refs/for
|
||||
----
|
||||
|
||||
If all these branches should be deleted it can be done with the
|
||||
following command:
|
||||
|
||||
----
|
||||
$ for n in $(git for-each-ref --format='%(refname)' refs/for);
|
||||
do git update-ref -d $n; done
|
||||
----
|
||||
|
||||
Branches under the 'refs/for/' namespace can be created by users that
|
||||
bypass Gerrit and push directly to the git repository itself (not
|
||||
using the Gerrit server's SSH port).
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
contains banned commit ...
|
||||
==========================
|
||||
|
||||
With this error message Gerrit rejects to push a commit that is
|
||||
banned or that would merge in an ancestor that is banned.
|
||||
|
||||
If a commit was identified as a bad commit (e.g. because it contains
|
||||
coding that violates intellectual property) and because of this it
|
||||
was removed from the central git repository it can be marked as
|
||||
banned. Gerrit will then prevent that this commit ever enters the
|
||||
repository again by rejecting every push of such a commit with the
|
||||
error message "contains banned commit ...".
|
||||
|
||||
If you have commits that you want to push that are based on a banned
|
||||
commit you may want to link:http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html[cherry-pick] them onto a clean base and push
|
||||
them again.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
... has duplicates
|
||||
==================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if its commit
|
||||
message contains a Change-ID for which multiple changes can be found
|
||||
in the project.
|
||||
|
||||
This error means that there is an inconsistency in Gerrit since for
|
||||
one project there are multiple changes that have the same Change-ID.
|
||||
Every change is expected to have an unique Change-ID.
|
||||
|
||||
Since this error should never occur in practice, you should inform
|
||||
your Gerrit administrator if you hit this problem and/or
|
||||
link:http://code.google.com/p/gerrit/issues/list[open a Gerrit issue].
|
||||
|
||||
In any case to not be blocked with your work, you can simply create a
|
||||
new Change-ID for your commit and then push it as new change to
|
||||
Gerrit. How to exchange the Change-ID in the commit message of your
|
||||
commit is explained link:error-push-fails-due-to-commit-message.html[here].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
invalid Change-Id line format in commit message
|
||||
===============================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if its commit
|
||||
message contains an invalid Change-Id line.
|
||||
|
||||
You can see the commit messages for existing commits in the history
|
||||
by doing a link:http://www.kernel.org/pub/software/scm/git/docs/git-log.html[git log].
|
||||
|
||||
If it was the intention to rework a change and to push a new patch
|
||||
set, find the change in the Gerrit WebUI, copy its Change-Id line and
|
||||
use it to correct the invalid Change-Id line in the commit message of
|
||||
the commit for which the push is failing. How to do this is explained
|
||||
link:error-push-fails-due-to-commit-message.html#commit_hook[here].
|
||||
|
||||
If it was the intention to create a new change in Gerrit simply
|
||||
remove the invalid Change-Id line from the commit message of the
|
||||
commit for which the push is failing. How to do this is explained
|
||||
link:error-push-fails-due-to-commit-message.html#commit_hook[here]. In case you have configured the link:cmd-hook-commit-msg.html[commit hook] a new valid
|
||||
Change-Id will be automatically generated and inserted.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:user-changeid.html[Change-Id Lines]
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
Gerrit Code Review - Error Messages
|
||||
===================================
|
||||
|
||||
This page provides access to detailed explanations of Gerrit error
|
||||
messages. For each error message it is explained why the error is
|
||||
occurring and what can be done to solve it.
|
||||
|
||||
|
||||
Error Messages
|
||||
--------------
|
||||
|
||||
* link:error-branch-not-found.html[branch ... not found]
|
||||
* link:error-change-closed.html[change ... closed]
|
||||
* link:error-change-does-not-belong-to-project.html[change ... does not belong to project ...]
|
||||
* link:error-change-not-found.html[change ... not found]
|
||||
* link:error-contains-banned-commit.html[contains banned commit ...]
|
||||
* link:error-has-duplicates.html[... has duplicates]
|
||||
* link:error-invalid-changeid-line.html[invalid Change-Id line format in commit message]
|
||||
* link:error-missing-changeid.html[missing Change-Id in commit message]
|
||||
* link:error-multiple-changeid-lines.html[multiple Change-Id lines in commit message]
|
||||
* link:error-no-changes-made.html[no changes made]
|
||||
* link:error-no-common-ancestry.html[no common ancestry]
|
||||
* link:error-no-new-changes.html[no new changes]
|
||||
* link:error-non-fast-forward.html[non-fast forward]
|
||||
* link:error-not-a-gerrit-administrator.html[Not a Gerrit administrator]
|
||||
* link:error-not-a-gerrit-project.html[not a Gerrit project]
|
||||
* link:error-not-permitted-to-create.html[Not permitted to create ...]
|
||||
* link:error-not-signed-off-by.html[not Signed-off-by author/committer/uploader]
|
||||
* link:error-not-valid-ref.html[not valid ref]
|
||||
* link:error-change-upload-blocked.html[One or more refs/for/ names blocks change upload]
|
||||
* link:error-permission-denied.html[Permission denied (publickey)]
|
||||
* link:error-prohibited-by-gerrit.html[prohibited by Gerrit]
|
||||
* link:error-squash-commits-first.html[squash commits first]
|
||||
* link:error-upload-denied.html[Upload denied for project \'...']
|
||||
* link:error-not-allowed-to-upload-merges.html[you are not allowed to upload merges]
|
||||
* link:error-you-are-not-author.html[you are not author ...]
|
||||
* link:error-you-are-not-committer.html[you are not committer ...]
|
||||
|
||||
|
||||
General Hints
|
||||
-------------
|
||||
|
||||
* link:error-push-fails-due-to-commit-message.html[push fails due to commit message]
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
missing Change-Id in commit message
|
||||
===================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit to a project
|
||||
which is configured to always require a Change-Id in the commit
|
||||
message if the commit message of the pushed commit does not contain
|
||||
a Change-Id.
|
||||
|
||||
This error may happen for two reasons:
|
||||
|
||||
. missing Change-Id in the commit message
|
||||
. Change-Id is contained in the commit message but not in the last
|
||||
paragraph
|
||||
|
||||
You can see the commit messages for existing commits in the history
|
||||
by doing a link:http://www.kernel.org/pub/software/scm/git/docs/git-log.html[git log].
|
||||
|
||||
To avoid this error you should use the link:cmd-hook-commit-msg.html[commit hook] or EGit to
|
||||
automatically create and insert a unique Change-Id into the commit
|
||||
message on every commit.
|
||||
|
||||
|
||||
Missing Change-Id in the commit message
|
||||
---------------------------------------
|
||||
|
||||
If the commit message of a commit that you want to push does not
|
||||
contain a Change-Id you have to update its commit message and insert
|
||||
a Change-Id.
|
||||
|
||||
If you want to upload a new change to Gerrit make sure that you have
|
||||
configured your environment so that a unique Change-Id is
|
||||
automatically created and inserted on every commit as explained
|
||||
above. Now you can rewrite the commits for which the Change-Ids are
|
||||
missing and the Change-Ids will be automatically created and inserted
|
||||
into the commit messages. This is explained link:error-push-fails-due-to-commit-message.html#commit_hook[here].
|
||||
|
||||
If you want to update an existing change in Gerrit by uploading a new
|
||||
patch set you should copy its Change-Id from the Gerrit WebUI and
|
||||
insert it into the commit message. How to update the commit message
|
||||
is explained link:error-push-fails-due-to-commit-message.html[here].
|
||||
|
||||
|
||||
Change-Id is contained in the commit message but not in the last paragraph
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
To be picked up by Gerrit, a Change-Id must be in the last paragraph
|
||||
of a commit message, for details, see link:user-changeid.html[Change-Id Lines].
|
||||
|
||||
If the Change-Id is contained in the commit message but not in its
|
||||
last paragraph you have to update the commit message and move the
|
||||
Change-ID into the last paragraph. How to update the commit message
|
||||
is explained link:error-push-fails-due-to-commit-message.html[here].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
multiple Change-Id lines in commit message
|
||||
==========================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if the commit
|
||||
message of the pushed commit contains several Change-Id lines.
|
||||
|
||||
You can see the commit messages for existing commits in the history
|
||||
by doing a link:http://www.kernel.org/pub/software/scm/git/docs/git-log.html[git log].
|
||||
|
||||
If it was the intention to rework a change and to push a new patch
|
||||
set, find the change in the Gerrit WebUI, copy its Change-Id line and
|
||||
use the copied Change-Id line instead of the existing Change-Id lines
|
||||
in the commit message of the commit for which the push is failing.
|
||||
How to do this is explained link:error-push-fails-due-to-commit-message.html#commit_hook[here].
|
||||
|
||||
If it was the intention to create a new change in Gerrit simply
|
||||
remove all Change-Id lines from the commit message of the
|
||||
commit for which the push is failing. How to do this is explained
|
||||
link:error-push-fails-due-to-commit-message.html#commit_hook[here]. In case you have configured the link:cmd-hook-commit-msg.html[commit hook] a new Change-Id
|
||||
will be automatically generated and inserted.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:user-changeid.html[Change-Id Lines]
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
no changes made
|
||||
===============
|
||||
|
||||
With this error message Gerrit rejects to push a commit as a new
|
||||
patch set for a change, if the pushed commit is identical with the
|
||||
current patch set of this change.
|
||||
|
||||
A pushed commit is considered to be identical with the current patch
|
||||
set if
|
||||
|
||||
- the files in the commit,
|
||||
- the commit message,
|
||||
- the author of the commit and
|
||||
- the parents of the commit
|
||||
|
||||
are all identical.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
no common ancestry
|
||||
==================
|
||||
|
||||
With this error message Gerrit rejects to push a commit for code
|
||||
review if the pushed commit and the commit at the tip of the target
|
||||
branch do not have a common ancestry.
|
||||
|
||||
This means that your local development history and the development
|
||||
history of the branch to which the push is done are completely
|
||||
independent (they have completely independent commit graphs).
|
||||
|
||||
This error usually occurs if you do a change in one project and then
|
||||
you accidentally push the commit to another project for code review.
|
||||
To fix the problem you should check your push specification and
|
||||
verify that you are pushing the commit to the correct project.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
no new changes
|
||||
==============
|
||||
|
||||
With this error message Gerrit rejects to push a commit if the pushed
|
||||
commit was already successfully pushed to Gerrit. In this case there
|
||||
is no new change and consequently there is nothing to do for Gerrit.
|
||||
|
||||
If your push is failing with this error message, you normally
|
||||
don't have to do anything since the commit was already successfully
|
||||
pushed. Still this error message may sometimes come as a surprise if
|
||||
you expected a new commit to be pushed. In this case you should
|
||||
verify that:
|
||||
|
||||
. your changes were successfully committed locally (otherwise there
|
||||
is no new commit which can be pushed)
|
||||
. you are pushing the correct commit (e.g. if you are pushing HEAD
|
||||
make sure you have locally checked out the correct branch)
|
||||
|
||||
If you are sure you are pushing the correct commit and you are still
|
||||
getting the "no new changes" error unexpectedly you can take the
|
||||
commit ID and search for the corresponding change in Gerrit. To do
|
||||
this simply paste the commit ID in the Gerrit WebUI into the search
|
||||
field. Details about how to search in Gerrit are explained link:user-search.html[here].
|
||||
|
||||
Please note that each commit can really be pushed only once. This
|
||||
means:
|
||||
|
||||
. you cannot push a commit again even if the change for which the
|
||||
commit was pushed before was abandoned (but you may restore the
|
||||
abandoned change)
|
||||
. you cannot reset a change to an old patch set by pushing the old
|
||||
commit for this change again
|
||||
. if a commit was pushed to one branch you cannot push this commit
|
||||
to another branch
|
||||
. if a commit was pushed directly to a branch (without going through
|
||||
code review) you cannot push this commit once again for code
|
||||
review (please note that in this case searching by the commit ID
|
||||
in the Gerrit WebUI will not find any change)
|
||||
|
||||
If you need to re-push a commit you may rewrite this commit by
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/git-commit.html[amending] it or doing an interactive link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[git rebase]. By rewriting the
|
||||
commit you actually create a new commit (with a new commit ID) which
|
||||
can then be pushed to Gerrit. If the old commit contains a Change-Id
|
||||
in the commit message you also need to replace it with a new
|
||||
Change-Id (case 1. and 3. above), otherwise the push will fail with
|
||||
another error message.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
non-fast forward
|
||||
================
|
||||
|
||||
With this error message Git rejects a push if the remote branch can't
|
||||
be fast forwarded onto the pushed commit. This is the case if the
|
||||
pushed commit is not based on the current tip of the remote branch.
|
||||
|
||||
If a non-fast forward update would be done, all commits from the
|
||||
remote branch that succeed the base commit of the pushed commit would
|
||||
be removed. This would be especially confusing for other users that
|
||||
have based their work on such a commit. Because of this Git is by
|
||||
default not allowing non-fast forward updates.
|
||||
|
||||
When working with Gerrit, this error can only occur if
|
||||
link:user-upload.html#bypass_review[code review is bypassed].
|
||||
|
||||
There are different reasons why this error can occur:
|
||||
|
||||
. the remote branch has evolved since you started your development
|
||||
. you are pushing the commit to the wrong project
|
||||
|
||||
|
||||
the remote branch has evolved since you started your development
|
||||
----------------------------------------------------------------
|
||||
|
||||
You start your development based on the current tip of the remote
|
||||
branch. While you implement your feature / bug-fix, a change in Gerrit
|
||||
gets submitted (or another user directly pushes a commit) so that the
|
||||
remote branch evolves. If you are now pushing your commit, with
|
||||
bypassing code review, your push will be rejected with the error
|
||||
message 'non-fast forward'. To solve the problem you have to either
|
||||
|
||||
. link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[rebase] your commit on the new tip of the remote branch or
|
||||
. link:http://www.kernel.org/pub/software/scm/git/docs/git-merge.html[merge] your commit with the new tip of the remote branch.
|
||||
|
||||
Afterwards the push should be successful.
|
||||
|
||||
|
||||
you are pushing the commit to the wrong project
|
||||
-----------------------------------------------
|
||||
|
||||
If you do a commit in one project and then accidentally push this
|
||||
commit, with bypassing code review, to another project, this will fail
|
||||
with the error message 'non-fast forward'. To fix the problem you
|
||||
should check the push specification and verify that you are pushing
|
||||
the commit to the correct project.
|
||||
|
||||
|
||||
Although it is considered as bad practice, it is possible to allow
|
||||
non-fast forward updates with Git. For this the remote Git repository
|
||||
has to be configured to not deny non-fast forward updates (set the
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/git-config.html[Git configuration] parameter 'receive.denyNonFastForwards' to
|
||||
'false'). Then it is possible to push a non-fast forward update by
|
||||
using the '--force' option.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
Not a Gerrit administrator
|
||||
==========================
|
||||
|
||||
With this error message Gerrit rejects to execute a SSH command that
|
||||
requires administrator privileges if the user is not a Gerrit
|
||||
administrator.
|
||||
|
||||
The Gerrit link:cmd-index.html#admin_commands[administrator commands] can only be executed by users who
|
||||
are member of the Gerrit link:access-control.html#administrators[Administrators] group.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
not a Gerrit project
|
||||
====================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if the git
|
||||
repository to which the push is done does not exist as a project in
|
||||
the Gerrit server or if the pushing user has no read access for this
|
||||
project.
|
||||
|
||||
The name of the project in Gerrit has the same name as the path of
|
||||
its git repository (excluding the '.git' extension).
|
||||
|
||||
If you are facing this problem, do the following:
|
||||
|
||||
. Verify that the project name specified as git repository in the
|
||||
push command is typed correctly (case sensitive).
|
||||
. Verify that you are pushing to the correct Gerrit server.
|
||||
. Go in the Gerrit WebUI to 'Admin' -> 'Projects' and check that the
|
||||
project is listed. If the project is not listed the project either
|
||||
does not exist or you don't have read access ('+1 Read Access' in
|
||||
the link:access-control.html#category_READ['Read Access'] category) for it. This means if you certain that
|
||||
the project name is right you should contact the Gerrit
|
||||
Administrator or project owner to request access to the project.
|
||||
|
||||
This error message might be misleading if the project actually exists
|
||||
but the push is failing because the pushing user has no read access
|
||||
for the project. The reason that Gerrit in this case denies the
|
||||
existence of the project is to prevent users from probing the Gerrit
|
||||
server to see if a particular project exists.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
you are not allowed to upload merges
|
||||
====================================
|
||||
|
||||
With this error message Gerrit rejects to push a merge commit if the
|
||||
pushing user has no permissions to upload merge commits for the
|
||||
project to which the push is done.
|
||||
|
||||
If you need to upload merge commits, you can contact one of the
|
||||
project owners and request for this project permissions to upload
|
||||
merge commits (access right '+3 Upload merges permission' in the
|
||||
link:access-control.html#category_READ['Read Access'] category).
|
||||
|
||||
If one of your changes could not be merged in Gerrit due to conflicts
|
||||
and you created the merge commit to resolve the conflicts, you might
|
||||
want to revert the merge and instead of this do a link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[rebase].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
Not permitted to create ...
|
||||
===========================
|
||||
|
||||
With this error message Gerrit rejects to create a new project in
|
||||
Gerrit if the user has no privileges for project creation.
|
||||
|
||||
In Gerrit it is possible to link:config-gerrit.html#repository[configure which groups are allowed to create projects].
|
||||
|
||||
If you are getting this error and you need to create projects in
|
||||
Gerrit you have to contact a Gerrit administrator and request
|
||||
permissions for project creation.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
not Signed-off-by author/committer/uploader
|
||||
===========================================
|
||||
|
||||
Projects in Gerrit can be configured to require a link:user-signedoffby.html#Signed-off-by[Signed-off-by] in
|
||||
the commit message to enforce that every change is signed by the
|
||||
author, committer or uploader. If for a project a Signed-off-by is
|
||||
required and the commit message does not contain it, Gerrit rejects
|
||||
to push the commit with this error message.
|
||||
|
||||
This policy can be bypassed by having the access right '+2 Forge
|
||||
Committer or Tagger Identity' in the link:access-control.html#category_FORG['Forge Identity'] category.
|
||||
|
||||
This error may happen for different reasons if you do not have the
|
||||
access right to forge the committer identity:
|
||||
|
||||
. missing Signed-off-by in the commit message
|
||||
. Signed-off-by is contained in the commit message but it's neither
|
||||
from the author, committer nor uploader
|
||||
. Signed-off-by from the author, committer or uploader is contained
|
||||
in the commit message but not in the last paragraph
|
||||
|
||||
To be able to push your commits you have to update the commit
|
||||
messages as explained link:error-push-fails-due-to-commit-message.html[here] so that they contain a Signed-off-by from
|
||||
the author, committer or uploader in the last paragraph. However it
|
||||
is important that you only add a Signed-off-by if you understand the
|
||||
semantics of the link:user-signedoffby.html#Signed-off-by[Signed-off-by] and the commit applies to the rules
|
||||
that are connected with this footer.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
not valid ref
|
||||
=============
|
||||
|
||||
With this error message Gerrit rejects to push a commit if the target
|
||||
ref in the push specification has an incorrect format (for example:
|
||||
'/refs/for/master', 'refs/for//master').
|
||||
|
||||
To solve the problem you have to correct the target ref in the push
|
||||
specification. Depending on whether you want to push your commit with
|
||||
or without code review the ref format is different:
|
||||
|
||||
|
||||
ref format for pushing a commit for code review:
|
||||
------------------------------------------------
|
||||
|
||||
If it was the intention to push a commit for code review the target
|
||||
ref in the push specification must be the project's magical ref
|
||||
`refs/for/'branch'` (where 'branch' must be replaced with the name
|
||||
of an existing branch to which you want to push your commit). Further
|
||||
details about how to push a commit for code review are explained at
|
||||
link:user-upload.html#push_create[Create Changes]).
|
||||
|
||||
Example for pushing a commit for code review to the 'master' branch:
|
||||
----
|
||||
$ git push ssh://JohnDoe@host:29418/myProject HEAD:refs/for/master
|
||||
----
|
||||
|
||||
|
||||
ref format for directly pushing a commit (without code review):
|
||||
---------------------------------------------------------------
|
||||
|
||||
If it was the intention to bypass code review and to push directly to
|
||||
a branch the target ref in the push specification must be the name of
|
||||
the branch to which you want to push. Further details about how to
|
||||
bypass code review are explained at link:user-upload.html#bypass_review[Bypass Review].
|
||||
|
||||
Example for pushing a commit directly to the 'master' branch (without
|
||||
code review):
|
||||
----
|
||||
$ git push ssh://JohnDoe@host:29418/myProject HEAD:master
|
||||
----
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,62 +0,0 @@
|
|||
Permission denied (publickey)
|
||||
=============================
|
||||
|
||||
With this error message a SSH command to Gerrit is rejected if the
|
||||
SSH authentication is not successful.
|
||||
|
||||
The link:http://en.wikipedia.org/wiki/Secure_Shell[SSH] protocol uses link:http://en.wikipedia.org/wiki/Public-key_cryptography[Public-key Cryptography] for authentication.
|
||||
This means for a successful SSH authentication you need your private
|
||||
SSH key and the corresponding public SSH key must be known to Gerrit.
|
||||
|
||||
If you are facing this problem, do the following:
|
||||
|
||||
. Verify that you are using the correct username for the SSH command
|
||||
and that it is typed correctly (case sensitive). You can look up
|
||||
your username in the Gerrit WebUI under 'Settings' -> 'Profile'.
|
||||
. Verify that you have uploaded your public SSH key for your Gerrit
|
||||
account. To do this go in the Gerrit WebUI to 'Settings' ->
|
||||
'SSH Public Keys' and check that your public SSH key is there. If
|
||||
your public SSH key is not there you have to upload it.
|
||||
. Verify that you are using the correct private SSH key. To find out
|
||||
which private SSH key is used test the SSH authentication as
|
||||
described below. From the trace you should see which private SSH
|
||||
key is used.
|
||||
|
||||
|
||||
Test SSH authentication
|
||||
-----------------------
|
||||
|
||||
To test the SSH authentication you can run the following SSH command.
|
||||
This command will print out a detailed trace which is helpful to
|
||||
analyze problems with the SSH authentication:
|
||||
|
||||
----
|
||||
$ ssh -vv -p 29418 john.doe@git.example.com
|
||||
----
|
||||
|
||||
If the SSH authentication is successful you should find the following
|
||||
lines in the output:
|
||||
|
||||
----
|
||||
...
|
||||
|
||||
debug1: Authentication succeeded (publickey).
|
||||
|
||||
...
|
||||
|
||||
**** Welcome to Gerrit Code Review ****
|
||||
|
||||
Hi John Doe, you have successfully connected over SSH.
|
||||
|
||||
Unfortunately, interactive shells are disabled.
|
||||
To clone a hosted Git repository, use:
|
||||
|
||||
git clone ssh://john.doe@git.example.com:29418/REPOSITORY_NAME.git
|
||||
|
||||
...
|
||||
----
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
prohibited by Gerrit
|
||||
====================
|
||||
|
||||
This is a general error message that is returned by Gerrit if a push
|
||||
is not allowed, e.g. because the pushing user has no sufficient
|
||||
privileges.
|
||||
|
||||
In particular this error occurs:
|
||||
|
||||
1. if you push a commit for code review to a branch for which you
|
||||
don't have upload permissions (access right '+2 Upload permission'
|
||||
in the link:access-control.html#category_READ['Read Access'] category)
|
||||
2. if you bypass code review without sufficient privileges in the
|
||||
link:access-control.html#category_pHD['Push Branch'] category
|
||||
3. if you push a signed or annotated tag without sufficient
|
||||
privileges in the link:access-control.html#category_pTAG['Push Tag'] category
|
||||
4. if you push a lightweight tag without the access right '+2 Create
|
||||
Branch' for the reference name 'refs/tags/*' in the link:access-control.html#category_pHD['Push Branch']
|
||||
category
|
||||
|
||||
For new users it happens often that they accidentally try to bypass
|
||||
code review. The push then fails with the error message 'prohibited
|
||||
by Gerrit' because the project didn't allow to bypass code review.
|
||||
Bypassing the code review is done by pushing directly to refs/heads/*
|
||||
(e.g. refs/heads/master) instead of pushing to refs/for/* (e.g.
|
||||
refs/for/master). Details about how to push commits for code review
|
||||
are explained link:user-upload.html#push_create[here].
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
Push fails due to commit message
|
||||
================================
|
||||
|
||||
If Gerrit rejects pushing a commit it is often the case that there is
|
||||
an issue with the commit message of the pushed commit. In this case
|
||||
often the problem can be resolved by fixing the commit message.
|
||||
|
||||
If the commit message of the last commit needs to be fixed you can
|
||||
simply amend the last commit (please find a detailed description in
|
||||
the link:http://www.kernel.org/pub/software/scm/git/docs/git-commit.html[Git documentation]):
|
||||
|
||||
----
|
||||
$ git commit --amend
|
||||
----
|
||||
|
||||
If you need to fix the commit messages of several commits or of any
|
||||
commit other than the last one you have to do an interactive git
|
||||
rebase for the affected commits. While doing the interactive rebase
|
||||
you can e.g. choose 'reword' for those commits for which you want to
|
||||
fix the commit messages. For a detailed description of git rebase
|
||||
please check the link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git documentation].
|
||||
|
||||
Please use interactive git rebase with care as it rewrites existing
|
||||
commits. Generally you should never rewrite commits that have already
|
||||
been submitted in Gerrit.
|
||||
|
||||
[[commit_hooks]]
|
||||
Sometimes commit hooks are used to automatically insert/update
|
||||
information in the commit message. If such information is missing in
|
||||
the commit message of existing commits (e.g. because the commit hook
|
||||
was only configured later) rewriting the commits will (re)execute the
|
||||
commit hook and so update the commit messages. If you do an
|
||||
interactive rebase to achieve this make sure that the affected
|
||||
commits are really rewritten, e.g. by choosing 'reword' for all these
|
||||
commits and then confirming all the commit messages. Just picking a
|
||||
commit may not rewrite it.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
squash commits first
|
||||
====================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if it
|
||||
contains the same Change-ID as a predecessor commit.
|
||||
|
||||
The reason for rejecting such a commit is that it would introduce, for
|
||||
the corresponding change in Gerrit, a dependency upon itself. Gerrit
|
||||
prevents such dependencies between patch sets within the same change
|
||||
to keep the review process simple. Otherwise reviewers would not only
|
||||
have to review the latest patch set but also all the patch sets the
|
||||
latest one is depending on.
|
||||
|
||||
This error is quite common, it appears when a user tries to address
|
||||
review comments and creates a new commit instead of amending the
|
||||
existing commit. Another possibility for this error, although less
|
||||
likely, is that the user tried to create a patch series with multiple
|
||||
changes to be reviewed and accidentally included the same Change-ID
|
||||
into the different commit messages.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Here an example about how the push is failing. Please note that the
|
||||
two commits 'one commit' and 'another commit' both have the same
|
||||
Change-ID (of course in real life it can happen that there are more
|
||||
than two commits that have the same Change-ID).
|
||||
|
||||
----
|
||||
$ git log
|
||||
commit 13d381265ffff88088e1af88d0e2c2c1143743cd
|
||||
Author: John Doe <john.doe@example.com>
|
||||
Date: Thu Dec 16 10:15:48 2010 +0100
|
||||
|
||||
another commit
|
||||
|
||||
Change-Id: I93478acac09965af91f03c82e55346214811ac79
|
||||
|
||||
commit ca45e125145b12fe9681864b123bc9daea501bf7
|
||||
Author: John Doe <john.doe@example.com>
|
||||
Date: Thu Dec 16 10:12:54 2010 +0100
|
||||
|
||||
one commit
|
||||
|
||||
Change-Id: I93478acac09965af91f03c82e55346214811ac79
|
||||
|
||||
$ git push ssh://JohnDoe@host:29418/myProject HEAD:refs/for/master
|
||||
Counting objects: 8, done.
|
||||
Delta compression using up to 2 threads.
|
||||
Compressing objects: 100% (2/2), done.
|
||||
Writing objects: 100% (6/6), 558 bytes, done.
|
||||
Total 6 (delta 0), reused 0 (delta 0)
|
||||
To ssh://JohnDoe@host:29418/myProject
|
||||
! [remote rejected] HEAD -> refs/for/master (squash commits first)
|
||||
error: failed to push some refs to 'ssh://JohnDoe@host:29418/myProject'
|
||||
----
|
||||
|
||||
If it was the intention to rework on a change and to push a new patch
|
||||
set the problem can be fixed by squashing the commits that contain the
|
||||
same Change-ID. The squashed commit can then be pushed to Gerrit.
|
||||
To squash the commits use git rebase to do an interactive rebase. For
|
||||
the example above where the last two commits have the same Change-ID
|
||||
this means an interactive rebase for the last two commits should be
|
||||
done. For further details about the git rebase command please check
|
||||
the link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git documentation for rebase].
|
||||
|
||||
----
|
||||
$ git rebase -i HEAD~2
|
||||
|
||||
pick ca45e12 one commit
|
||||
squash 13d3812 another commit
|
||||
|
||||
[detached HEAD ab37207] squashed commit
|
||||
1 files changed, 3 insertions(+), 0 deletions(-)
|
||||
Successfully rebased and updated refs/heads/master.
|
||||
|
||||
$ git log
|
||||
commit ab37207d33647685801dba36cb4fd51f3eb73507
|
||||
Author: John Doe <john.doe@example.com>
|
||||
Date: Thu Dec 16 10:12:54 2010 +0100
|
||||
|
||||
squashed commit
|
||||
|
||||
Change-Id: I93478acac09965af91f03c82e55346214811ac79
|
||||
|
||||
$ git push ssh://JohnDoe@host:29418/myProject HEAD:refs/for/master
|
||||
Counting objects: 5, done.
|
||||
Writing objects: 100% (3/3), 307 bytes, done.
|
||||
Total 3 (delta 0), reused 0 (delta 0)
|
||||
To ssh://JohnDoe@host:29418/myProject
|
||||
* [new branch] HEAD -> refs/for/master
|
||||
----
|
||||
|
||||
If it was the intention to create a patch series with multiple
|
||||
changes to be reviewed each commit message should contain the
|
||||
Change-ID of the corresponding change in Gerrit, if a change in
|
||||
Gerrit does not exist yet, the Change-ID should be generated (either
|
||||
by using a link:cmd-hook-commit-msg.html[commit hook] or by using EGit) or the Change-ID could be
|
||||
removed (not recommended since then amending this commit to create
|
||||
subsequent patch sets is more error prone). To change the Change-ID
|
||||
of an existing commit do an interactive link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[git rebase] and fix the
|
||||
affected commit messages.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
Upload denied for project \'...'
|
||||
=================================
|
||||
|
||||
With this error message Gerrit rejects to push a commit if the
|
||||
pushing user has no upload permissions for the project to which the
|
||||
push was done.
|
||||
|
||||
There are two possibilities how to continue in this situation:
|
||||
|
||||
. contact one of the project owners and request upload permissions
|
||||
for the project (access right '+2 Upload permission' in the
|
||||
link:access-control.html#category_READ['Read Access'] category)
|
||||
. export your commit as a patch using the link:http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html[git format-patch] command
|
||||
and provide the patch file to one of the project owners
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,145 +0,0 @@
|
|||
you are not author ...
|
||||
======================
|
||||
|
||||
Gerrit verifies for every pushed commit that the e-mail address of
|
||||
the author matches one of the registered e-mail addresses of the
|
||||
pushing user. If this is not the case pushing the commit fails with
|
||||
the error message "you are not author ...". This policy can be
|
||||
bypassed by having the access right '+1 Forge Author Identity' in the
|
||||
link:access-control.html#category_FORG['Forge Identity'] category.
|
||||
|
||||
This error may happen for two reasons:
|
||||
|
||||
. incorrect configuration of the e-mail address on client or server side
|
||||
. missing privileges to push commits of other authors
|
||||
|
||||
|
||||
Incorrect configuration of the e-mail address on client or server side
|
||||
----------------------------------------------------------------------
|
||||
|
||||
If pushing to Gerrit fails with the error message "you are not
|
||||
author ..." and you are the author of the commit for which the push
|
||||
fails, then either you have not successfully registered this e-mail
|
||||
address for your Gerrit account or the author information of the
|
||||
pushed commit is incorrect.
|
||||
|
||||
Configuration of e-mail address in Gerrit
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Check in Gerrit under 'Settings -> Identities' which e-mail addresses
|
||||
you've configured for your Gerrit account, if no e-mail address is
|
||||
registered go to 'Settings -> Contact Information' and register a new
|
||||
e-mail address there. Make sure you confirm your e-mail address by
|
||||
clicking on the link in the e-mail verification mail sent by Gerrit.
|
||||
If you don't receive the e-mail verification mail it might be that it
|
||||
was caught by your spam filter.
|
||||
|
||||
Incorrect author information
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For every commit Git maintains the author. If not explicitly
|
||||
specified Git computes the author on commit out of the Git
|
||||
configuration parameters 'user.name' and 'user.email'.
|
||||
|
||||
----
|
||||
$ git config -l
|
||||
...
|
||||
user.name=John Doe
|
||||
user.email=john.doe@example.com
|
||||
...
|
||||
----
|
||||
|
||||
A commit done with the above Git configuration would have
|
||||
"John Doe <john.doe@example.com>" as author.
|
||||
|
||||
You can see the author information for existing commits in the
|
||||
history.
|
||||
|
||||
----
|
||||
$ git log
|
||||
commit cbe31bdba7d14963eb42f7e1e0eef1fe58698c05
|
||||
Author: John Doe <john.doe@example.com>
|
||||
Date: Mon Dec 20 15:36:33 2010 +0100
|
||||
|
||||
my commit
|
||||
|
||||
----
|
||||
|
||||
Check in Git that the author information of the commit that should
|
||||
be pushed is correct. The author should have the same e-mail address
|
||||
that you've configured for your Gerrit account. If the author
|
||||
information is incorrect set the Git configuration parameters
|
||||
'user.name' and 'user.email' to the correct values (you might want to
|
||||
set this globally by including the option '--global'):
|
||||
|
||||
----
|
||||
$ git config user.name "John Doe"
|
||||
$
|
||||
$ git config user.email john.doe@example.com
|
||||
$
|
||||
----
|
||||
|
||||
Now you should update the author for those commits where the author
|
||||
information is wrong. If only the last commit is affected you can do
|
||||
this by amending the last commit and explicitly setting the author:
|
||||
|
||||
----
|
||||
$ git commit --amend --author "John Doe <john.doe@example.com>"
|
||||
----
|
||||
|
||||
If you need to update the author information for several commits it
|
||||
gets more complicated. In this case you have to do an interactive
|
||||
git rebase for the affected commits. While doing the interactive
|
||||
rebase you have to choose 'edit' for those commits for which the
|
||||
author should be rewritten. When the rebase stops at such a commit
|
||||
you have to amend the commit with explicitly setting the author
|
||||
before continuing the rebase.
|
||||
|
||||
Here is an exmaple that shows how the interactive rebase is used to
|
||||
update the author for the last 3 commits:
|
||||
|
||||
----
|
||||
$ git rebase -i HEAD~3
|
||||
|
||||
edit 51f0d47 one commit
|
||||
edit 7299690 another commit
|
||||
edit 304ad96 one more commit
|
||||
|
||||
Stopped at 51f0d47... one commit
|
||||
You can amend the commit now, with
|
||||
|
||||
git commit --amend
|
||||
|
||||
Once you are satisfied with your changes, run
|
||||
|
||||
git rebase --continue
|
||||
|
||||
$ git commit --amend --author "John Doe <john.doe@example.com>"
|
||||
[detached HEAD baea1e4] one commit
|
||||
Author: John Doe <john.doe@example.com>
|
||||
1 files changed, 4 insertions(+), 1 deletions(-)
|
||||
|
||||
$ git rebase --continue
|
||||
|
||||
...
|
||||
----
|
||||
|
||||
For further details about git rebase please check the
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git documentation].
|
||||
|
||||
|
||||
Missing privileges to push commits of other users
|
||||
-------------------------------------------------
|
||||
|
||||
If pushing to Gerrit fails with the error message "you are not
|
||||
author ..." and somebody else is author of the commit for which the
|
||||
push fails, then you have no permissions to forge the author
|
||||
identity. In this case you may contact the project owner to request
|
||||
the access right '+1 Forge Author Identity' in the 'Forge Identity'
|
||||
category or ask the maintainer to commit this change on the author's
|
||||
behalf.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,110 +0,0 @@
|
|||
you are not committer ...
|
||||
=========================
|
||||
|
||||
Gerrit verifies for every pushed commit that the e-mail address of
|
||||
the committer matches one of the registered e-mail addresses of the
|
||||
pushing user. If this is not the case pushing the commit fails with
|
||||
the error message "you are not committer ...". This policy can be
|
||||
bypassed by having the access right '+2 Forge Committer or Tagger
|
||||
Identity' in the link:access-control.html#category_FORG['Forge Identity'] category.
|
||||
|
||||
This error may happen for two reasons:
|
||||
|
||||
. incorrect configuration of the e-mail address on client or server
|
||||
side
|
||||
. missing privileges to push commits that were committed by other
|
||||
users
|
||||
|
||||
|
||||
Incorrect configuration of the e-mail address on client or server side
|
||||
----------------------------------------------------------------------
|
||||
|
||||
If pushing to Gerrit fails with the error message "you are not
|
||||
committer ..." and you committed the change for which the push fails,
|
||||
then either you have not successfully registered this e-mail address
|
||||
for your Gerrit account or the committer information of the pushed
|
||||
commit is incorrect.
|
||||
|
||||
Configuration of e-mail address in Gerrit
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Check in Gerrit under 'Settings -> Identities' which e-mail addresses
|
||||
you've configured for your Gerrit account, if no e-mail address is
|
||||
registered go to 'Settings -> Contact Information' and register a new
|
||||
e-mail address there. Make sure you confirm your e-mail address by
|
||||
clicking on the link in the e-mail verification mail sent by Gerrit.
|
||||
|
||||
Incorrect committer information
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For every commit Git maintains the user who did the commit, the so
|
||||
called committer. Git computes the committer out of the Git
|
||||
configuration parameters 'user.name' and 'user.email'.
|
||||
|
||||
----
|
||||
$ git config -l
|
||||
...
|
||||
user.name=John Doe
|
||||
user.email=john.doe@example.com
|
||||
...
|
||||
----
|
||||
|
||||
A commit done with the above Git configuration would have
|
||||
"John Doe <john.doe@example.com>" as committer.
|
||||
|
||||
To see the committer information for existing commits do
|
||||
"git log --format=full":
|
||||
|
||||
----
|
||||
$ git log --format=full
|
||||
commit cbe31bdba7d14963eb42f7e1e0eef1fe58698c05
|
||||
Author: John Doe <john.doe@example.com>
|
||||
Commit: John Doe <john.doe@example.com>
|
||||
|
||||
my commit
|
||||
|
||||
----
|
||||
|
||||
Check in Git that the committer information of the commit that should
|
||||
be pushed is correct. As explained above you can do this by
|
||||
'git log --format=full'. The committer should have the same e-mail
|
||||
address that you've configured for your Gerrit account. If the
|
||||
committer information is incorrect set the Git configuration
|
||||
parameters 'user.name' and 'user.email' to the correct values (you
|
||||
might want to set this globally by including the option '--global'):
|
||||
|
||||
----
|
||||
$ git config user.name "John Doe"
|
||||
$
|
||||
$ git config user.email john.doe@example.com
|
||||
$
|
||||
----
|
||||
|
||||
Now you should rewrite the commits for which the committer
|
||||
information is wrong. If only the last commit is affected you can do
|
||||
this by doing a 'commit --amend'. If you need to update the committer
|
||||
information for several commits it gets more complicated. In this
|
||||
case you have to do an interactive git rebase for the affected
|
||||
commits. While doing the interactive rebase you have to ensure that
|
||||
the commits are rewritten (e.g. by choosing 'reword' for all these
|
||||
commits and then confirming all the commit messages). Just picking
|
||||
all the changes will not work as in this case the committer is not
|
||||
rewritten. For further details about git rebase please check the
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git documentation].
|
||||
|
||||
|
||||
Missing privileges to push commits that were committed by other users
|
||||
---------------------------------------------------------------------
|
||||
|
||||
If pushing to Gerrit fails with the error message "you are not
|
||||
committer ..." and somebody else committed the change for which the
|
||||
push fails, then you have no permissions to forge the committer
|
||||
identity. In this case you may contact the project owner to request
|
||||
the access right '+2 Forge Committer or Tagger Identity' in the
|
||||
'Forge Identity' category or ask the maintainer to commit this change
|
||||
on the author's behalf.
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:error-messages.html[Gerrit Error Messages]
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
Gerrit Code Review - i18n
|
||||
=========================
|
||||
|
||||
Aside from actually writing translations, there's some issues with
|
||||
the way the code produces output. Most of the UI should support
|
||||
right-to-left (RTL) languages.
|
||||
|
||||
|
||||
ApprovalCategory
|
||||
----------------
|
||||
|
||||
The getName() function produces only a single translation of the
|
||||
description string. This name is set by the Gerrit administrator,
|
||||
which may cause problems if the site is translated into multiple
|
||||
langauges and different users want different translations.
|
||||
|
||||
ApprovalCategoryValue
|
||||
---------------------
|
||||
|
||||
The getName() function produces only a single translation of the
|
||||
description string. This name is set by the Gerrit administrator,
|
||||
which may cause problems if the site is translated into multiple
|
||||
langauges and different users want different translations.
|
||||
|
||||
/Gerrit Gerrit.html
|
||||
-------------------
|
||||
|
||||
* The title of the host page is not translated.
|
||||
|
||||
* The <noscript> tag is not translated.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
Gerrit Code Review for Git
|
||||
==========================
|
||||
|
||||
User Guide
|
||||
----------
|
||||
|
||||
* link:http://source.android.com/submit-patches/workflow[Default Workflow]
|
||||
* link:user-search.html[Searching Changes]
|
||||
* link:cmd-index.html[Command Line Tools]
|
||||
* link:pgm-index.html[Server Programs]
|
||||
* link:user-upload.html[Uploading Changes]
|
||||
* link:user-changeid.html[Change-Id Lines]
|
||||
* link:user-signedoffby.html[Signed-off-by Lines]
|
||||
* link:access-control.html[Access Controls]
|
||||
* link:error-messages.html[Error Messages]
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
* link:licenses.html[Licenses and Notices]
|
||||
* link:install.html[Installation Guide]
|
||||
* link:project-setup.html[Project Setup]
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
* link:config-gerrit.html[System Settings]
|
||||
* link:config-contact.html[User Contact Information]
|
||||
* link:config-replication.html[Git Replication/Mirroring]
|
||||
* link:config-gitweb.html[Gitweb Integration]
|
||||
* link:config-headerfooter.html[Site Header/Footer]
|
||||
* link:config-sso.html[Single Sign-On Systems]
|
||||
* link:config-reverseproxy.html[Reverse Proxy]
|
||||
* link:config-hooks.html[Hooks]
|
||||
* link:config-mail.html[Mail Templates]
|
||||
|
||||
Developer Documentation
|
||||
-----------------------
|
||||
|
||||
* link:dev-readme.html[Developer Setup]
|
||||
* link:dev-eclipse.html[Eclipse Setup]
|
||||
* link:dev-design.html[System Design]
|
||||
* link:i18n-readme.html[i18n Support]
|
||||
|
||||
Resources
|
||||
---------
|
||||
|
||||
* link:http://code.google.com/p/gerrit/[Homepage]
|
||||
* link:http://code.google.com/p/gerrit/downloads/list[Downloads]
|
||||
* link:http://code.google.com/p/gerrit/issues/list[Issue Tracking]
|
||||
* link:http://code.google.com/p/gerrit/wiki/Source?tm=4[Source Code]
|
||||
* link:http://code.google.com/p/gerrit/wiki/Background[A History of Gerrit Code Review]
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
Gerrit Code Review - J2EE Installation
|
||||
======================================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Gerrit binary distributions include a standalone Jetty servlet
|
||||
container, but are packaged as a standard WAR file to permit easy
|
||||
deployment to other existing container installations if using the
|
||||
standalone daemon is not desired.
|
||||
|
||||
Gerrit Code Review can be installed into any J2EE servlet container,
|
||||
including popular open source containers such as Jetty or Tomcat, or
|
||||
any commerical server which supports the J2EE servlet specification.
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
* Complete the link:install.html#createdb[database setup] and
|
||||
link:install.html#init[site initialization] tasks described
|
||||
in the standard installation documentation.
|
||||
|
||||
* Stop the embedded deamon that was automatically started by 'init':
|
||||
+
|
||||
----
|
||||
review_site/bin/gerrit.sh stop
|
||||
----
|
||||
|
||||
* Deploy the 'gerrit.war' file to your application server.
|
||||
+
|
||||
The deployment process differs between servers, but typically this
|
||||
can be accomplished by copying 'gerrit.war' into the 'webapps/'
|
||||
subdirectory of the container's installation.
|
||||
|
||||
* Configure JNDI DataSource 'jdbc/ReviewDb'.
|
||||
+
|
||||
This DataSource must point to the database you created above.
|
||||
Don't forget to ensure your JNDI configuration can load the
|
||||
necessary JDBC drivers. You may wish to ensure connection pooling
|
||||
is configured and enabled within the DataSource.
|
||||
|
||||
* ('Optional') Install Bouncy Castle Crypto API
|
||||
+
|
||||
If you enabled Bouncy Castle Crypto during 'init', copy the JAR
|
||||
from `'$site_path'/lib` into your servlet container's extensions
|
||||
directory so its available to Gerrit Code Review.
|
||||
|
||||
|
||||
Jetty 7.x
|
||||
---------
|
||||
These directions will configure Gerrit as the default web
|
||||
application, allowing URLs like `http://example.com/4543` to jump
|
||||
directly to change 4543.
|
||||
|
||||
Download and unzip a release version of Jetty. From here on we
|
||||
call the unpacked directory `$JETTY_HOME`.
|
||||
|
||||
* link:http://www.eclipse.org/jetty/downloads.php[Jetty Downloads]
|
||||
|
||||
If this is a fresh installation of Jetty, move into the installation
|
||||
directory and do some cleanup to remove the sample webapps:
|
||||
----
|
||||
cd $JETTY_HOME
|
||||
rm -rf contexts/* webapps/*
|
||||
----
|
||||
|
||||
Copy Gerrit Code Review into the deployment:
|
||||
----
|
||||
cp ~/gerrit.war webapps/gerrit.war
|
||||
java -jar webapps/gerrit.war cat extra/jetty7/gerrit.xml >contexts/gerrit.xml
|
||||
----
|
||||
|
||||
Install the required additional libraries by copying them into the
|
||||
`'$JETTY_HOME'/lib/ext` directory:
|
||||
|
||||
----
|
||||
cp ../review_db/lib/* lib/ext/
|
||||
java -jar webapps/gerrit.war cat lib/commons-dbcp-1.2.2.jar >lib/ext/commons-dbcp-1.2.2.jar
|
||||
java -jar webapps/gerrit.war cat lib/commons-pool-1.5.4.jar >lib/ext/commons-pool-1.5.4.jar
|
||||
java -jar webapps/gerrit.war cat lib/h2-1.2.128.jar >lib/ext/h2-1.2.128.jar
|
||||
java -jar webapps/gerrit.war cat lib/postgresql-8.4-701.jdbc4.jar >lib/ext/postgresql-8.4-701.jdbc4.jar
|
||||
----
|
||||
|
||||
Edit `'$JETTY_HOME'/contexts/gerrit.xml` to correctly configure
|
||||
the database and outgoing SMTP connections, especially the user
|
||||
and password fields.
|
||||
|
||||
If OpenID authentication (or certain enterprise single-sign-on
|
||||
solutions) is being used, you may need to increase the
|
||||
header buffer size parameter, due to very long header lines
|
||||
being used by the OpenID authentication handshake process.
|
||||
Add the following to `'$JETTY_HOME'/etc/jetty.xml` under
|
||||
`org.eclipse.jetty.server.nio.SelectChannelConnector`:
|
||||
|
||||
----
|
||||
<Set name="headerBufferSize">16384</Set>
|
||||
----
|
||||
|
||||
To start automatically when the system boots, create a start
|
||||
script and modify it for your configuration:
|
||||
|
||||
----
|
||||
java -jar webapps/gerrit.war --cat extra/jetty7/gerrit-jetty.sh >/etc/init.d/gerrit-jetty.sh
|
||||
vi /etc/init.d/gerrit-jetty.sh
|
||||
----
|
||||
|
||||
[TIP]
|
||||
Under Jetty, restarting the web application (e.g. after modifying
|
||||
`system_config`) is as simple as touching the context config file:
|
||||
`'$JETTY_HOME'/contexts/gerrit.xml`
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,192 +0,0 @@
|
|||
Gerrit Code Review - Installation Guide
|
||||
=======================================
|
||||
|
||||
You need a SQL database to house the review metadata. Currently H2,
|
||||
MySQL and PostgreSQL are the only supported databases.
|
||||
|
||||
[[download]]
|
||||
Download Gerrit
|
||||
---------------
|
||||
|
||||
Current and past binary releases of Gerrit can be obtained from
|
||||
the downloads page at the project site:
|
||||
|
||||
* http://code.google.com/p/gerrit/downloads/list[Gerrit Downloads]
|
||||
|
||||
Download any current `*.war` package. The war will be referred to as
|
||||
`gerrit.war` from this point forward, so you may find it easier to
|
||||
rename the downloaded file.
|
||||
|
||||
If you would prefer to build Gerrit directly from source, review
|
||||
the notes under link:dev-readme.html[developer setup].
|
||||
|
||||
[[createdb]]
|
||||
Database Setup
|
||||
--------------
|
||||
|
||||
[[createdb_h2]]
|
||||
H2
|
||||
~~
|
||||
|
||||
During init Gerrit will automatically configure the embedded H2
|
||||
database. No additional configuration is necessary. Using the
|
||||
embedded H2 database is the easiest way to get a Gerrit site up
|
||||
and running.
|
||||
|
||||
[[createdb_postgres]]
|
||||
PostgreSQL
|
||||
~~~~~~~~~~
|
||||
|
||||
Create a user for the web application within Postgres, assign it a
|
||||
password, create a database to store the metadata, and grant the user
|
||||
full rights on the newly created database:
|
||||
|
||||
----
|
||||
createuser -A -D -P -E gerrit2
|
||||
createdb -E UTF-8 -O gerrit2 reviewdb
|
||||
----
|
||||
|
||||
[[createdb_mysql]]
|
||||
MySQL
|
||||
~~~~~
|
||||
|
||||
Create a user for the web application within the database, assign it a
|
||||
password, create a database, and give the newly created user full
|
||||
rights on it:
|
||||
|
||||
----
|
||||
mysql
|
||||
|
||||
CREATE USER 'gerrit2'@'localhost' IDENTIFIED BY 'secret';
|
||||
CREATE DATABASE reviewdb;
|
||||
ALTER DATABASE reviewdb charset=latin1;
|
||||
GRANT ALL ON reviewdb.* TO 'gerrit2'@'localhost';
|
||||
FLUSH PRIVILEGES;
|
||||
----
|
||||
|
||||
|
||||
[[init]]
|
||||
Initialize the Site
|
||||
-------------------
|
||||
|
||||
Gerrit stores configuration files, the server's SSH keys, and the
|
||||
managed Git repositories under a local directory, typically referred
|
||||
to as `'$site_path'`. If the embedded H2 database is being used,
|
||||
its data files will also be stored under this directory.
|
||||
|
||||
Initialize a new site directory by running the init command, passing
|
||||
the path of the site directory to be created as an argument to the
|
||||
'-d' option. Its recommended that Gerrit Code Review be given its
|
||||
own user account on the host system:
|
||||
|
||||
----
|
||||
sudo adduser gerrit2
|
||||
sudo su gerrit2
|
||||
cd ~gerrit2
|
||||
|
||||
java -jar gerrit.war init -d review_site
|
||||
----
|
||||
|
||||
If run from an interactive terminal, 'init' will prompt through a
|
||||
series of configuration questions, including gathering information
|
||||
about the database created above. If the terminal is not interactive
|
||||
init will make some reasonable default selections, and will use the
|
||||
embedded H2 database.
|
||||
|
||||
Init may need to download additional JARs to support optional selected
|
||||
functionality. If a download fails a URL will be displayed and init
|
||||
will wait for the user to manually download the JAR and store it in
|
||||
the target location.
|
||||
|
||||
When 'init' is complete, the daemon will be automatically started
|
||||
in the background and your web browser will open to the site:
|
||||
|
||||
----
|
||||
Initialized /home/gerrit2/review_site
|
||||
Executing /home/gerrit2/review_site/bin/gerrit.sh start
|
||||
Starting Gerrit Code Review: OK
|
||||
Waiting for server to start ... OK
|
||||
Opening browser ...
|
||||
----
|
||||
|
||||
When the browser opens, sign in to Gerrit through the web interface.
|
||||
The first user to sign-in and register an account will be
|
||||
automatically placed into the fully privileged Administrators group,
|
||||
permitting server management over the web and over SSH. Subsequent
|
||||
users will be automatically registered as unprivileged users.
|
||||
|
||||
|
||||
[[project_setup]]
|
||||
Project Setup
|
||||
-------------
|
||||
|
||||
See link:project-setup.html[Project Setup] for further details on
|
||||
how to register a new project with Gerrit. This step is necessary
|
||||
if existing Git repositories were not imported during 'init'.
|
||||
|
||||
|
||||
[[rc_d]]
|
||||
Start/Stop Daemon
|
||||
-----------------
|
||||
|
||||
To control the Gerrit Code Review daemon that is running in the
|
||||
background, use the rc.d style start script created by 'init':
|
||||
|
||||
====
|
||||
review_site/bin/gerrit.sh start
|
||||
review_site/bin/gerrit.sh stop
|
||||
review_site/bin/gerrit.sh restart
|
||||
====
|
||||
|
||||
('Optional') Link the gerrit.sh script into rc3.d so the daemon
|
||||
automatically starts and stops with the operating system:
|
||||
|
||||
====
|
||||
sudo ln -snf `pwd`/review_site/bin/gerrit.sh /etc/init.d/gerrit.sh
|
||||
sudo ln -snf ../init.d/gerrit.sh /etc/rc3.d/S90gerrit
|
||||
====
|
||||
|
||||
To install Gerrit into an existing servlet container instead of using
|
||||
the embedded Jetty server, see
|
||||
link:install-j2ee.html[J2EE installation].
|
||||
|
||||
|
||||
[[customize]]
|
||||
Site Customization
|
||||
------------------
|
||||
|
||||
Gerrit Code Review supports some site-specific customization options.
|
||||
For more information, see the related topic in this manual:
|
||||
|
||||
* link:config-reverseproxy.html[Reverse Proxy]
|
||||
* link:config-sso.html[Single Sign-On Systems]
|
||||
* link:config-replication.html[Git Replication/Mirroring]
|
||||
* link:config-headerfooter.html[Site Header/Footer]
|
||||
* link:config-gitweb.html[Gitweb Integration]
|
||||
* link:config-gerrit.html[Other System Settings]
|
||||
|
||||
|
||||
[[anonymous_access]]
|
||||
Anonymous Access
|
||||
----------------
|
||||
|
||||
Exporting the Git repository directory
|
||||
(link:config-gerrit.html#gerrit.basePath[gerrit.basePath]) over the
|
||||
anonymous, unencrypted git:// protocol is more efficient than
|
||||
Gerrit's internal SSH daemon. See the `git-daemon` documentation
|
||||
for details on how to configure this if anonymous access is desired.
|
||||
|
||||
* http://www.kernel.org/pub/software/scm/git/docs/git-daemon.html[man git-daemon]
|
||||
|
||||
|
||||
External Documentation Links
|
||||
----------------------------
|
||||
|
||||
* http://www.postgresql.org/docs/[PostgreSQL Documentation]
|
||||
* http://dev.mysql.com/doc/[MySQL Documentation]
|
||||
* http://www.kernel.org/pub/software/scm/git/docs/git-daemon.html[git-daemon]
|
||||
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
Gerrit Code Review - JSON Data
|
||||
==============================
|
||||
|
||||
Some commands produce JSON data streams intended for other
|
||||
applications to consume. The structures are documented below.
|
||||
Note that any field may be missing in the JSON messages, so consumers
|
||||
of this JSON stream should deal with that appropriately.
|
||||
|
||||
[[change]]
|
||||
change
|
||||
------
|
||||
The Gerrit change being reviewed, or that was already reviewed.
|
||||
|
||||
project:: Project path in Gerrit
|
||||
|
||||
branch:: Branch name within project
|
||||
|
||||
topic:: Topic name specified by the uploader for this change series
|
||||
|
||||
id:: Change identifier, as scraped out of the Change-Id field in
|
||||
the commit message, or as assigned by the server if it was missing.
|
||||
|
||||
number:: Change number (deprecated)
|
||||
|
||||
subject:: Description of change
|
||||
|
||||
owner:: Owner in <<account,account attribute>>
|
||||
|
||||
url:: Canonical URL to reach this change
|
||||
|
||||
lastUpdated:: Time in seconds since the UNIX epoch when this change
|
||||
was last updated.
|
||||
|
||||
sortKey:: Internal key used to sort changes, based on lastUpdated.
|
||||
|
||||
open:: Boolean indicating if the change is still open for review.
|
||||
|
||||
status:: Current state of this change.
|
||||
|
||||
NEW;; Change is still being reviewed.
|
||||
|
||||
SUBMITTED;; Change has been submitted and is in the merge queue.
|
||||
It may be waiting for one or more dependencies.
|
||||
|
||||
MERGED;; Change has been merged to its branch.
|
||||
|
||||
ABANDONED;; Change was abandoned by its owner or administrator.
|
||||
|
||||
trackingIds:: Issue tracking system links in
|
||||
<<trackingid,trackingid attribute>>, scraped out of the commit
|
||||
message based on the server's
|
||||
link:config-gerrit.html#trackingid[trackingid] sections.
|
||||
|
||||
currentPatchSet:: Current <<patchset,patchset attribute>>.
|
||||
|
||||
patchSets:: All <<patchset,patchset attribute>> for this change.
|
||||
|
||||
[[trackingid]]
|
||||
trackingid
|
||||
----------
|
||||
A link to an issue tracking system.
|
||||
|
||||
system:: Name of the system. This comes straight from the
|
||||
gerrit.config file.
|
||||
|
||||
id:: Id number as scraped out of the commit message.
|
||||
|
||||
[[account]]
|
||||
account
|
||||
-------
|
||||
A user account.
|
||||
|
||||
name:: User's full name, if configured.
|
||||
|
||||
email:: User's preferred email address.
|
||||
|
||||
[[patchset]]
|
||||
patchset
|
||||
--------
|
||||
Refers to a specific patchset within a <<change,change>>.
|
||||
|
||||
number:: The patchset number.
|
||||
|
||||
revision:: Git commit for this patchset.
|
||||
|
||||
ref:: Git reference pointing at the revision. This reference is
|
||||
available through the Gerrit Code Review server's Git interface
|
||||
for the containing change.
|
||||
|
||||
uploader:: Uploader of the patch set in <<account,account attribute>>.
|
||||
|
||||
approvals:: The <<approval,approval attribute>> granted.
|
||||
|
||||
[[approval]]
|
||||
approval
|
||||
--------
|
||||
Records the code review approval granted to a patch set.
|
||||
|
||||
type:: Internal name of the approval given.
|
||||
|
||||
description:: Human readable category of the approval.
|
||||
|
||||
value:: Value assigned by the approval, usually a numerical score.
|
||||
|
||||
grantedOn:: Time in seconds since the UNIX epoch when this approval
|
||||
was added or last updated.
|
||||
|
||||
by:: Reviewer of the patch set in <<account,account attribute>>.
|
||||
|
||||
[[refupdate]]
|
||||
refupdate
|
||||
--------
|
||||
Information about a ref that was updated.
|
||||
|
||||
oldRev:: The old value of the ref, prior to the update.
|
||||
|
||||
newRev:: The new value the ref was updated to.
|
||||
|
||||
project:: Project path in Gerrit
|
||||
|
||||
refName:: Ref name within project.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
* link:cmd-stream-events.html[gerrit stream-events]
|
||||
* link:cmd-query.html[gerrit query]
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,50 +0,0 @@
|
|||
ExportReviewNotes
|
||||
=================
|
||||
|
||||
NAME
|
||||
----
|
||||
ExportReviewNotes - Export successful reviews to refs/notes/review
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'java' -jar gerrit.war 'ExportReviewNotes' -d <SITE_PATH>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Scans every submitted change and creates an initial notes
|
||||
branch detailing the previous submission information for
|
||||
each merged changed.
|
||||
|
||||
This task can take quite some time, but can run in the background
|
||||
concurrently to the server if the database is MySQL or PostgreSQL.
|
||||
If the database is H2, this task must be run by itself.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-d::
|
||||
\--site-path::
|
||||
Location of the gerrit.config file, and all other per-site
|
||||
configuration data, supporting libaries and log files.
|
||||
|
||||
\--threads::
|
||||
Number of threads to perform the scan work with. Default: 2.
|
||||
|
||||
CONTEXT
|
||||
-------
|
||||
This command can only be run on a server which has direct
|
||||
connectivity to the metadata database, and local access to the
|
||||
managed Git repositories.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
To generate all review information:
|
||||
|
||||
====
|
||||
$ java -jar gerrit.war ExportReviewNotes -d site_path --threads 16
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
ScanTrackingIds
|
||||
===============
|
||||
|
||||
NAME
|
||||
----
|
||||
ScanTrackingIds - Rescan changes to index trackingids
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'java' -jar gerrit.war 'ScanTrackingIds' -d <SITE_PATH>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Scans every known change and updates the indexed tracking
|
||||
ids associated with the change, after editing the trackingid
|
||||
configuration in gerrit.config.
|
||||
|
||||
This task can take quite some time, but can run in the background
|
||||
concurrently to the server if the database is MySQL or PostgreSQL.
|
||||
If the database is H2, this task must be run by itself.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-d::
|
||||
\--site-path::
|
||||
Location of the gerrit.config file, and all other per-site
|
||||
configuration data, supporting libaries and log files.
|
||||
|
||||
\--threads::
|
||||
Number of threads to perform the scan work with. Defaults to
|
||||
twice the number of CPUs available.
|
||||
|
||||
CONTEXT
|
||||
-------
|
||||
This command can only be run on a server which has direct
|
||||
connectivity to the metadata database, and local access to the
|
||||
managed Git repositories.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
To rescan all known trackingids:
|
||||
|
||||
====
|
||||
$ java -jar gerrit.war ScanTrackingIds -d site_path --threads 16
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,109 +0,0 @@
|
|||
daemon
|
||||
======
|
||||
|
||||
NAME
|
||||
----
|
||||
daemon - Gerrit network server
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'java' -jar gerrit.war 'daemon'
|
||||
-d <SITE_PATH>
|
||||
[\--enable-httpd | \--disable-httpd]
|
||||
[\--enable-sshd | \--disable-sshd]
|
||||
[\--console-log]
|
||||
[\--slave]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Runs the Gerrit network daemon on the local system, configured as
|
||||
per the local copy of link:config-gerrit.html[gerrit.config].
|
||||
|
||||
The path to gerrit.config is read from the metadata database,
|
||||
which requires that all slaves (and master) reading from the same
|
||||
database must place gerrit.config at the same location on the local
|
||||
filesystem. However, any option within gerrit.config, including
|
||||
link:config-gerrit.html#gerrit.basePath[gerrit.basePath] may be set
|
||||
to different values.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-d::
|
||||
\--site-path::
|
||||
Location of the gerrit.config file, and all other per-site
|
||||
configuration data, supporting libaries and log files.
|
||||
|
||||
\--enable-httpd::
|
||||
\--disable-httpd::
|
||||
Enable (or disable) the internal HTTP daemon, answering
|
||||
web requests. Enabled by default.
|
||||
|
||||
\--enable-sshd::
|
||||
\--disable-sshd::
|
||||
Enable (or disable) the internal SSH daemon, answering SSH
|
||||
clients and remotely executed commands. Enabled by default.
|
||||
|
||||
\--slave::
|
||||
Run in slave mode, permitting only read operations
|
||||
by clients. Commands which modify state such as
|
||||
link:cmd-receive-pack.html[recieve-pack] (creates new changes
|
||||
or updates existing ones) or link:cmd-review.html[review]
|
||||
(sets approve marks) are disabled.
|
||||
+
|
||||
This option automatically implies '\--disable-httpd \--enable-sshd'.
|
||||
|
||||
\--console-log::
|
||||
Send log messages to the console, instead of to the standard
|
||||
log file '$site_path/logs/error_log'.
|
||||
|
||||
CONTEXT
|
||||
-------
|
||||
This command can only be run on a server which has direct
|
||||
connectivity to the metadata database, and local access to the
|
||||
managed Git repositories.
|
||||
|
||||
LOGGING
|
||||
-------
|
||||
Error and warning messages from the server are automatically written
|
||||
to the log file under '$site_path/logs/error_log'. This log file
|
||||
is automatically rotated at 12:00 AM GMT each day, allowing an
|
||||
external log cleaning service to clean up the prior logs.
|
||||
|
||||
KNOWN ISSUES
|
||||
------------
|
||||
Slave daemon caches can quickly become out of date when modifications
|
||||
are made on the master. The following configuration is suggested in
|
||||
a slave to reduce the maxAge for each cache entry, so that changes
|
||||
are recognized in a reasonable period of time:
|
||||
|
||||
----
|
||||
[cache "accounts"]
|
||||
maxAge = 5 min
|
||||
[cache "accounts_byemail"]
|
||||
maxAge = 5 min
|
||||
[cache "diff"]
|
||||
maxAge = 5 min
|
||||
[cache "groups"]
|
||||
maxAge = 5 min
|
||||
[cache "projects"]
|
||||
maxAge = 5 min
|
||||
[cache "sshkeys"]
|
||||
maxAge = 5 min
|
||||
----
|
||||
|
||||
and if LDAP support was enabled, also include:
|
||||
----
|
||||
[cache "ldap_groups"]
|
||||
maxAge = 5 min
|
||||
[cache "ldap_usernames"]
|
||||
maxAge = 5 min
|
||||
----
|
||||
|
||||
Automatic cache coherency between master and slave systems is
|
||||
planned to be implemented in a future version.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
gsql
|
||||
====
|
||||
|
||||
NAME
|
||||
----
|
||||
gsql - Administrative interface to idle database
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'java' -jar gerrit.war 'gsql' -d <SITE_PATH>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Interactive query support against the configured SQL database.
|
||||
All SQL statements are supported, including SELECT, UPDATE, INSERT,
|
||||
DELETE and ALTER.
|
||||
|
||||
This command is primarily intended to access a local H2 database
|
||||
which is not currently open by a Gerrit daemon. To access an open
|
||||
database use link:cmd-gsql.html[gerrit gsql] over SSH.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
-d::
|
||||
\--site-path::
|
||||
Location of the gerrit.config file, and all other per-site
|
||||
configuration data, supporting libaries and log files.
|
||||
|
||||
CONTEXT
|
||||
-------
|
||||
This command can only be run on a server which has direct
|
||||
connectivity to the metadata database, and local access to the
|
||||
managed Git repositories.
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
To manually correct a user's SSH user name:
|
||||
|
||||
====
|
||||
$ java -jar gerrit.war gsql
|
||||
Welcome to Gerrit Code Review v2.0.25
|
||||
(PostgreSQL 8.3.8)
|
||||
|
||||
Type '\h' for help. Type '\r' to clear the buffer.
|
||||
|
||||
gerrit> update accounts set ssh_user_name = 'alice' where account_id=1;
|
||||
UPDATE 1; 1 ms
|
||||
gerrit> \q
|
||||
Bye
|
||||
====
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
Gerrit Code Review - Server Programs
|
||||
====================================
|
||||
|
||||
Server side programs can be started by executing the WAR file
|
||||
through the Java command line. For example:
|
||||
|
||||
$ java -jar gerrit.war program [options]
|
||||
|
||||
[[programs]]Programs
|
||||
--------------------
|
||||
|
||||
link:pgm-init.html[init]::
|
||||
Initialize a new Gerrit server installation
|
||||
|
||||
link:pgm-daemon.html[daemon]::
|
||||
Gerrit HTTP, SSH network server.
|
||||
|
||||
link:pgm-gsql.html[gsql]::
|
||||
Administrative interface to idle database.
|
||||
|
||||
link:pgm-ExportReviewNotes.html[ExportReviewNotes]::
|
||||
Export submitted review information to refs/notes/review.
|
||||
|
||||
link:pgm-ScanTrackingIds.html[ScanTrackingIds]::
|
||||
Rescan all changes after configuring trackingids.
|
||||
|
||||
version::
|
||||
Display the release version of Gerrit Code Review.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
init
|
||||
====
|
||||
|
||||
NAME
|
||||
----
|
||||
init - Initialize a new Gerrit server installation
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'java' -jar gerrit.war 'init'
|
||||
-d <SITE_PATH>
|
||||
[\--batch]
|
||||
[\--no-auto-start]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Creates a new Gerrit server installation, interactively prompting
|
||||
for some basic setup prior to writing default configuration files
|
||||
into a newly created `$site_path`.
|
||||
|
||||
If run an an existing `$site_path`, init will upgrade some resources
|
||||
as necessary.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
\--batch::
|
||||
Run in batch mode, skipping interactive prompts. Reasonable
|
||||
configuration defaults are chosen based on the whims of
|
||||
the Gerrit developers.
|
||||
|
||||
\--no-auto-start::
|
||||
Don't automatically start the daemon after initializing a
|
||||
newly created site path. This permits the administartor
|
||||
to inspect and modify the configuration before the daemon
|
||||
is started.
|
||||
|
||||
-d::
|
||||
\--site-path::
|
||||
Location of the gerrit.config file, and all other per-site
|
||||
configuration data, supporting libaries and log files.
|
||||
|
||||
CONTEXT
|
||||
-------
|
||||
This command can only be run on a server which has direct
|
||||
connectivity to the metadata database, and local access to the
|
||||
managed Git repositories.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,140 +0,0 @@
|
|||
Gerrit Code Review - Project Configuration
|
||||
==========================================
|
||||
|
||||
All Git repositories under gerrit.basePath must be registered in
|
||||
the Gerrit database in order to be accessed through SSH, or through
|
||||
the web interface.
|
||||
|
||||
Create Through SSH
|
||||
------------------
|
||||
|
||||
Creating a new repository over SSH is perhaps the easiest way to
|
||||
configure a new project:
|
||||
|
||||
====
|
||||
ssh -p 29418 review.example.com gerrit create-project --name new/project
|
||||
====
|
||||
|
||||
See link:cmd-create-project.html[gerrit create-project] for more
|
||||
details.
|
||||
|
||||
|
||||
Manual Creation
|
||||
---------------
|
||||
|
||||
Projects may also be manually registered with the database.
|
||||
|
||||
Create Git Repository
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create a Git repository under gerrit.basePath:
|
||||
|
||||
====
|
||||
git --git-dir=$base_path/new/project.git init
|
||||
====
|
||||
|
||||
[TIP]
|
||||
By tradition the repository directory name should have a `.git`
|
||||
suffix.
|
||||
|
||||
To also make this repository available over the anonymous git://
|
||||
protocol, don't forget to create a `git-daemon-export-ok` file:
|
||||
|
||||
====
|
||||
touch $base_path/new/project.git/git-daemon-export-ok
|
||||
====
|
||||
|
||||
Register Project
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
One insert is needed to register a project with Gerrit.
|
||||
|
||||
[NOTE]
|
||||
Note that the `.git` suffix is not typically included in the
|
||||
project name, as it looks cleaner in the web when not shown.
|
||||
Gerrit automatically assumes that `project.git` is the Git repository
|
||||
for a project named `project`.
|
||||
|
||||
====
|
||||
INSERT INTO projects
|
||||
(use_contributor_agreements
|
||||
,submit_type
|
||||
,name)
|
||||
VALUES
|
||||
('N'
|
||||
,'M'
|
||||
,'new/project');
|
||||
====
|
||||
|
||||
[[submit_type]]
|
||||
Change Submit Action
|
||||
--------------------
|
||||
|
||||
The method Gerrit uses to submit a change to a project can be
|
||||
modified by any project owner through the project console, `Admin` >
|
||||
`Projects`. The following methods are supported:
|
||||
|
||||
* Fast Forward Only
|
||||
+
|
||||
This method produces a strictly linear history. All merges must
|
||||
be handled on the client, prior to uploading to Gerrit for review.
|
||||
+
|
||||
To submit a change, the change must be a strict superset of the
|
||||
destination branch. That is, the change must already contain the
|
||||
tip of the destination branch at submit time.
|
||||
|
||||
* Merge If Necessary
|
||||
+
|
||||
This is the default for a new project (and why `\'M'` is suggested
|
||||
above in the insert statement).
|
||||
+
|
||||
If the change being submitted is a strict superset of the destination
|
||||
branch, then the branch is fast-forwarded to the change. If not,
|
||||
then a merge commit is automatically created. This is identical
|
||||
to the classical `git merge` behavior, or `git merge \--ff`.
|
||||
|
||||
* Always Merge
|
||||
+
|
||||
Always produce a merge commit, even if the change is a strict
|
||||
superset of the destination branch. This is identical to the
|
||||
behavior of `git merge \--no-ff`, and may be useful if the
|
||||
project needs to follow submits with `git log \--first-parent`.
|
||||
|
||||
* Cherry Pick
|
||||
+
|
||||
Always cherry pick the patch set, ignoring the parent lineage
|
||||
and instead creating a brand new commit on top of the current
|
||||
branch head.
|
||||
+
|
||||
When cherry picking a change, Gerrit automatically appends onto the
|
||||
end of the commit message a short summary of the change's approvals,
|
||||
and a URL link back to the change on the web. The committer header
|
||||
is also set to the submitter, while the author header retains the
|
||||
original patch set author.
|
||||
+
|
||||
Note that Gerrit ignores patch set dependencies when operating in
|
||||
cherry-pick mode. Submitters must remember to submit changes in
|
||||
the right order since inter-change dependencies will not be
|
||||
enforced for them.
|
||||
|
||||
|
||||
Registering Additional Branches
|
||||
-------------------------------
|
||||
|
||||
Branches can be created over the SSH port by any `git push` client,
|
||||
if the user has been granted the `Push Branch` > `Create Branch`
|
||||
(or higher) access right.
|
||||
|
||||
Additional branches can also be created through the web UI, assuming
|
||||
at least one commit already exists in the project repository.
|
||||
A project owner can create additional branches under `Admin` >
|
||||
`Projects` > `Branches`. Enter the new branch name, and the
|
||||
starting Git revision. Branch names that don't start with `refs/`
|
||||
will automatically have `refs/heads/` prefixed to ensure they are
|
||||
a standard Git branch name. Almost any valid SHA-1 expression can
|
||||
be used to specify the starting revision, so long as it resolves
|
||||
to a commit object. Abbreviated SHA-1s are not supported.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
Gerrit Code Review - Change-Ids
|
||||
===============================
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Gerrit Code Review sometimes relies upon Change-Id lines in the
|
||||
bottom of a commit message to uniquely identify a change across all
|
||||
drafts of it. By including a unique Change-Id in the commit message,
|
||||
Gerrit can automatically associate a new version of a change back
|
||||
to its original review, even across cherry-picks and rebases.
|
||||
|
||||
To be picked up by Gerrit, a Change-Id line must be in the bottom
|
||||
portion (last paragraph) of a commit message, and may be mixed
|
||||
together with the Signed-off-by, Acked-by, or other such footers.
|
||||
For example:
|
||||
|
||||
----
|
||||
$ git log -1
|
||||
commit 29a6bb1a059aef021ac39d342499191278518d1d
|
||||
Author: A. U. Thor <author@example.com>
|
||||
Date: Thu Aug 20 12:46:50 2009 -0700
|
||||
|
||||
Improve foo widget by attaching a bar.
|
||||
|
||||
We want a bar, because it improves the foo by providing more
|
||||
wizbangery to the dowhatimeanery.
|
||||
|
||||
Bug: #42
|
||||
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b
|
||||
Signed-off-by: A. U. Thor <author@example.com>
|
||||
CC: R. E. Viewer <reviewer@example.com>
|
||||
----
|
||||
|
||||
In the above example, `Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b`
|
||||
is the unique identity assigned to this change. It does not match
|
||||
the commit name, `29a6...`, as the change may have been amended or
|
||||
rebased to address reviewer comments since its initial inception.
|
||||
|
||||
To avoid confusion with commit names, Change-Ids typically are with
|
||||
an uppercase `I`.
|
||||
|
||||
Creation
|
||||
--------
|
||||
|
||||
Gerrit Code Review provides a standard 'commit-msg' hook which
|
||||
can be installed in the local Git repository to automatically
|
||||
create and insert a unique Change-Id line during `git commit`.
|
||||
To install the hook, copy it from Gerrit's daemon:
|
||||
|
||||
$ scp -p -P 29418 john.doe@review.example.com:hooks/commit-msg .git/hooks/
|
||||
|
||||
$ curl http://review.example.com/tools/hooks/commit-msg
|
||||
|
||||
For more details, see link:cmd-hook-commit-msg.html[commit-msg].
|
||||
|
||||
Change Upload
|
||||
--------------
|
||||
|
||||
During upload by pushing to a `refs/for/\*` or `refs/heads/\*`
|
||||
branch, Gerrit will use the Change-Id line to:
|
||||
|
||||
* Create a new change
|
||||
+
|
||||
If this is the first time it has seen the Change-Id mentioned in
|
||||
the commit message, Gerrit will create a new change for review.
|
||||
|
||||
* Update an existing change
|
||||
+
|
||||
If Gerrit has seen this Change-Id before, but has not yet seen this
|
||||
new commit object, Gerrit will add the new commit as a new patch
|
||||
set on the existing change.
|
||||
|
||||
* Close an existing change
|
||||
+
|
||||
If Gerrit has seen this Change-Id before, and the commit is being
|
||||
pushed directly into a branch, the existing change is updated with
|
||||
the new commit, and the change is closed and marked as merged.
|
||||
|
||||
If a Change-Id line is not present in the commit message, Gerrit will
|
||||
automatically generate its own Change-Id and display it on the web.
|
||||
This line can be manually copied and inserted into an updated commit
|
||||
message if additional revisions to a change are required.
|
||||
|
||||
For more details on using git push to upload changes to Gerrit,
|
||||
see link:user-upload.html#push_create[creating changes by git push].
|
||||
|
||||
Git Tasks
|
||||
---------
|
||||
|
||||
[[new]]
|
||||
Creating a new commit
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When creating a new commit, ensure the 'commit-msg' hook has been
|
||||
installed in your repository (see above), and don't put a Change-Id
|
||||
line in the commit message. When you exit the editor, git will call
|
||||
the hook, which will automatically generate and insert a unique
|
||||
Change-Id line. You can inspect the modified message after the
|
||||
commit is complete by executing `git show`.
|
||||
|
||||
[[amend]]
|
||||
Amending a commit
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When amending a commit with `git commit \--amend`, leave the
|
||||
Change-Id line unmodified in the commit message. This will allow
|
||||
Gerrit to automatically update the change with the amended commit.
|
||||
|
||||
[[rebase]]
|
||||
Rebasing a commit
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When rebasing a commit, leave the Change-Id line unmodified in the
|
||||
commit message. This will allow Gerrit to automatically update
|
||||
the change with the rebased commit.
|
||||
|
||||
[[squash]]
|
||||
Squashing commits
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
When squashing several commits together, try to preserve only one
|
||||
Change-Id line, and remove the others from the commit message.
|
||||
When faced with multiple lines, try to preserve a line which was
|
||||
already uploaded to Gerrit Code Review, and thus has a corresponding
|
||||
change that reviewers have already examined and left comments on.
|
||||
If you aren't sure which lines Gerrit knows about, try copying and
|
||||
pasting the lines into the search box in the top-right.
|
||||
|
||||
If Gerrit already knows about more than one Change-Id, pick one
|
||||
to keep in the squashed commit message, and manually abandon the
|
||||
other changes through the web interface.
|
||||
|
||||
[[cherry-pick]]
|
||||
Cherry-picking a commit
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When cherry-picking a commit, leave the Change-Id line alone to
|
||||
have Gerrit treat the cherry-picked commit as a replacement for
|
||||
the existing change. This can be very useful if the project has
|
||||
a fast-forward-only merge policy, and the submitter is downloading
|
||||
and cherry-picking individual changes prior to submission, such as
|
||||
by link:cmd-cherry-pick.html[gerrit-cherry-pick].
|
||||
|
||||
Or, you may wish to delete the Change-Id line and force a new
|
||||
Change-Id to be generated automatically, thus creating an entirely
|
||||
new change record for review. This may be useful when backporting
|
||||
a change from the current development branch to a maintenance
|
||||
release branch.
|
||||
|
||||
[[update-old]]
|
||||
Updating an old commit
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If a commit was created before the availability of Change-Id support,
|
||||
or was created in a Git repository that was missing the 'commit-msg'
|
||||
hook, simply copy the "`Change-Id: I...`" line from the first line
|
||||
of the Description section of the change and amend it to the bottom
|
||||
of the commit message. Any subsequent uploads of the commit will
|
||||
be automatically associated with the prior change.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,413 +0,0 @@
|
|||
Gerrit Code Review - Searching Changes
|
||||
======================================
|
||||
|
||||
Default Searches
|
||||
----------------
|
||||
|
||||
Most basic searches can be viewed by clicking on a link along the top
|
||||
menu bar. The link will prefill the search box with a common search
|
||||
query, execute it, and present the results. If exactly one change
|
||||
matches the search, the change will be presented instead of a list.
|
||||
|
||||
|
||||
[options="header"]
|
||||
|=================================================
|
||||
|Description | Default Query
|
||||
|All > Open | status:open '(or is:open)'
|
||||
|All > Merged | status:merged
|
||||
|All > Abandoned | status:abandoned
|
||||
|My > Dafts | has:draft
|
||||
|My > Watched Changes | status:open is:watched
|
||||
|My > Starred Changes | is:starred
|
||||
|Open changes in Foo | status:open project:Foo
|
||||
|=================================================
|
||||
|
||||
Basic Change Search
|
||||
-------------------
|
||||
|
||||
Similar to many popular search engines on the web, just enter some
|
||||
text and let Gerrit figure out the meaning:
|
||||
|
||||
[options="header"]
|
||||
|=============================================================
|
||||
|Description | Examples
|
||||
|Legacy numerical id | 15183
|
||||
|Full or abbreviated Change-Id | Ic0ff33
|
||||
|Full or abbreviated commit SHA-1 | d81b32ef
|
||||
|Email address | user@example.com
|
||||
|Approval requirement | CodeReview>=+2, Verified=1
|
||||
|=============================================================
|
||||
|
||||
|
||||
Search Operators
|
||||
----------------
|
||||
|
||||
Operators act as restrictions on the search. As more operators
|
||||
are added to the same query string, they further restrict the
|
||||
returned results. Search can also be performed by typing only a
|
||||
text with no operator. It will try to match a project name by
|
||||
substring.
|
||||
|
||||
E.g. Searching for just "gerrit is:starred" will try to match a
|
||||
project name by "gerrit" as substring.
|
||||
|
||||
[[age]]
|
||||
age:'AGE'::
|
||||
+
|
||||
Amount of time that has expired since the change was last updated
|
||||
with a review comment or new patch set. The age must be specified
|
||||
to include a unit suffix, for example `age:2d`:
|
||||
+
|
||||
* s, sec, second, seconds
|
||||
* m, min, minute, minutes
|
||||
* h, hr, hour, hours
|
||||
* d, day, days
|
||||
* w, week, weeks (`1 week` is treated as `7 days`)
|
||||
* mon, month, months (`1 month` is treated as `30 days`)
|
||||
* y, year, years (`1 year` is treated as `365 days`)
|
||||
|
||||
[[change]]
|
||||
change:'ID'::
|
||||
+
|
||||
Either a legacy numerical 'ID' such as 15183, or a newer style
|
||||
Change-Id that was scraped out of the commit message.
|
||||
|
||||
[[owner]]
|
||||
owner:'USER'::
|
||||
+
|
||||
Changes originally submitted by 'USER'.
|
||||
|
||||
[[ownerin]]
|
||||
ownerin:'GROUP'::
|
||||
+
|
||||
Changes originally submitted by a user in 'GROUP'.
|
||||
|
||||
[[reviewer]]
|
||||
reviewer:'USER'::
|
||||
+
|
||||
Changes that have been, or need to be, reviewed by 'USER'.
|
||||
|
||||
[[reviewerin]]
|
||||
reviewerin:'GROUP'::
|
||||
+
|
||||
Changes that have been, or need to be, reviewed by a user in 'GROUP'.
|
||||
|
||||
[[commit]]
|
||||
commit:'SHA1'::
|
||||
+
|
||||
Changes where 'SHA1' is one of the patch sets of the change.
|
||||
|
||||
[[project]]
|
||||
project:'PROJECT'::
|
||||
+
|
||||
Changes occuring in 'PROJECT'. If 'PROJECT' starts with `^` it
|
||||
matches project names by regular expression. The
|
||||
link:http://www.brics.dk/automaton/[dk.brics.automaton
|
||||
library] is used for evaluation of such patterns.
|
||||
|
||||
|
||||
[[branch]]
|
||||
branch:'BRANCH'::
|
||||
+
|
||||
Changes for 'BRANCH'. The branch name is the short name shown
|
||||
in the web interface, without the traditional 'refs/heads/'
|
||||
prefix. This operator is a shorthand for 'refs:'. Searching for
|
||||
'branch:master' really means 'ref:refs/heads/master', and searching
|
||||
for 'branch:refs/heads/master' is the same as searching for
|
||||
'ref:refs/heads/refs/heads/master'.
|
||||
+
|
||||
If 'BRANCH' starts with `^` it matches branch names by regular
|
||||
expression patterns. The
|
||||
link:http://www.brics.dk/automaton/[dk.brics.automaton
|
||||
library] is used for evaluation of such patterns.
|
||||
|
||||
[[topic]]
|
||||
topic:'TOPIC'::
|
||||
+
|
||||
Changes whose designated topic at upload was 'TOPIC'. This is
|
||||
often combined with 'branch:' and 'project:' operators to select
|
||||
all related changes in a series.
|
||||
+
|
||||
If 'TOPIC' starts with `^` it matches topic names by regular
|
||||
expression patterns. The
|
||||
link:http://www.brics.dk/automaton/[dk.brics.automaton
|
||||
library] is used for evaluation of such patterns.
|
||||
|
||||
[[ref]]
|
||||
ref:'REF'::
|
||||
+
|
||||
Changes where the destination branch is exactly the given 'REF'
|
||||
name. Since 'REF' is absolute from the top of the repository it
|
||||
must start with 'refs/'.
|
||||
+
|
||||
If 'REF' starts with `^` it matches reference names by regular
|
||||
expression patterns. The
|
||||
link:http://www.brics.dk/automaton/[dk.brics.automaton
|
||||
library] is used for evaluation of such patterns.
|
||||
|
||||
[[tr,bug]]
|
||||
tr:'ID', bug:'ID'::
|
||||
+
|
||||
Search for changes whose commit message contains 'ID' and matched
|
||||
one or more of the
|
||||
link:config-gerrit.html#trackingid[trackingid sections]
|
||||
in the server's configuration file. This is typically used to
|
||||
search for changes that fix a bug or defect by the issue tracking
|
||||
system's issue identifier.
|
||||
|
||||
[[label]]
|
||||
label:'VALUE'::
|
||||
+
|
||||
Matches changes where the approval score 'VALUE' has been set during
|
||||
a review. See <<labels,labels>> below for more detail on the format
|
||||
of the argument.
|
||||
|
||||
[[message]]
|
||||
message:'MESSAGE'::
|
||||
+
|
||||
Changes that matches 'MESSAGE' arbitrary string in body commit messages.
|
||||
|
||||
[[file]]
|
||||
file:^'REGEX'::
|
||||
+
|
||||
Matches any change where REGEX matches a file that was affected
|
||||
by the change. The regular expression pattern must start with
|
||||
`^`. For example, to match all XML files use `file:^.*\.xml$`.
|
||||
The link:http://www.brics.dk/automaton/[dk.brics.automaton
|
||||
library] is used for the evaluation of such patterns.
|
||||
+
|
||||
The `^` required at the beginning of the regular expression not only
|
||||
denotes a regular expression, but it also has the usual meaning of
|
||||
anchoring the match to the start of the string. To match all Java
|
||||
files, use `file:^.*\.java`.
|
||||
+
|
||||
The entire regular expression pattern, including the `\^` character,
|
||||
should be double quoted when using more complex construction (like
|
||||
ones using a bracket expression). For example, to match all XML
|
||||
files named like 'name1.xml', 'name2.xml', and 'name3.xml' use
|
||||
`\file:"\^name[1-3].xml"`.
|
||||
+
|
||||
Currently this operator is only available on a watched project
|
||||
and may not be used in the search bar.
|
||||
|
||||
[[has]]
|
||||
has:draft::
|
||||
+
|
||||
True if there is a draft comment saved by the current user.
|
||||
|
||||
has:star::
|
||||
+
|
||||
Same as 'is:starred', true if the change has been starred by the
|
||||
current user.
|
||||
|
||||
[[is]]
|
||||
is:starred::
|
||||
+
|
||||
Same as 'has:star', true if the change has been starred by the
|
||||
current user.
|
||||
|
||||
is:watched::
|
||||
+
|
||||
True if this change matches one of the current user's watch filters,
|
||||
and thus is likely to notify the user when it updates.
|
||||
|
||||
is:reviewed::
|
||||
+
|
||||
True if there is at least one non-zero score on the change, in any
|
||||
approval category, by any user.
|
||||
|
||||
is:open::
|
||||
+
|
||||
True if the change is other open or submitted, merge pending.
|
||||
|
||||
is:closed::
|
||||
+
|
||||
True if the change is either merged or abandoned.
|
||||
|
||||
is:submitted, is:merged, is:abandoned::
|
||||
+
|
||||
Same as <<status,status:'STATE'>>.
|
||||
|
||||
[[status]]
|
||||
status:open::
|
||||
+
|
||||
True if the change state is other 'review in progress' or 'submitted,
|
||||
merge pending'.
|
||||
|
||||
status:reviewed::
|
||||
+
|
||||
Same as 'is:reviewed', matches if there is at least one non-zero
|
||||
score on the change, in any approval category, by any user.
|
||||
|
||||
status:submitted::
|
||||
+
|
||||
Change has been submitted, but is waiting for a dependency.
|
||||
|
||||
status:closed::
|
||||
+
|
||||
True if the change is either 'merged' or 'abandoned'.
|
||||
|
||||
status:merged::
|
||||
+
|
||||
Change has been merged into the branch.
|
||||
|
||||
status:abandoned::
|
||||
+
|
||||
Change has been abandoned by the change owner, or administrator.
|
||||
|
||||
|
||||
Boolean Operators
|
||||
-----------------
|
||||
|
||||
Unless otherwise specified, operators are joined using the `AND`
|
||||
boolean operator, thereby restricting the search results.
|
||||
|
||||
Parentheses can be used to force a particular precendence on complex
|
||||
operator expressions, otherwise OR has higher precendence than AND.
|
||||
|
||||
Negation
|
||||
~~~~~~~~
|
||||
Any operator can be negated by prefixing it with `-`, for example
|
||||
`-is:starred` is the exact opposite of `is:starred` and will
|
||||
therefore return changes that are *not* starred by the current user.
|
||||
|
||||
The operator `NOT` (in all caps) is a synonym.
|
||||
|
||||
AND
|
||||
~~~
|
||||
The boolean operator `AND` (in all caps) can be used to join two
|
||||
other operators together. This results in a restriction of the
|
||||
results, returning only changes that match both operators.
|
||||
|
||||
OR
|
||||
~~
|
||||
The boolean operator `OR` (in all caps) can be used to find changes
|
||||
that match either operator. This increases the nubmer of results
|
||||
that are returned, as more changes are considered.
|
||||
|
||||
|
||||
[[labels]]
|
||||
Labels
|
||||
------
|
||||
Label operators can be used to match approval score given during
|
||||
a code review. The specific set of supported labels depends on
|
||||
the server configuration, however `CodeReview` and `Verified`
|
||||
are the default labels provided out of the box.
|
||||
|
||||
A label name is any of the following:
|
||||
|
||||
* The category name. If the category name contains spaces,
|
||||
it must be wrapped in double quotes. Example: `label:"Code Review"`.
|
||||
|
||||
* The name, without spaces. This avoids needing to use double quotes
|
||||
for the common category Code Review. Example: `label:CodeReview`.
|
||||
|
||||
* The internal short name. Example: `label:CRVW`, or `label:VRIF`.
|
||||
|
||||
* The one or two character abbreviation shown in the column header
|
||||
of change list pages. Example: `label:R` or `label:V`.
|
||||
|
||||
A label name must be followed by a score, or an operator and a score.
|
||||
The easiest way to explain these are by example.
|
||||
|
||||
`label:CodeReview=2`::
|
||||
`label:CodeReview=+2`::
|
||||
`label:CodeReview+2`::
|
||||
+
|
||||
Matches changes where there is at least one \+2 score for Code Review.
|
||||
The \+ prefix is optional for positive score values. If the + is used,
|
||||
the = operator is optional.
|
||||
|
||||
`label:CodeReview=-2`::
|
||||
`label:CodeReview-2`::
|
||||
+
|
||||
Matches changes where there is at least one -2 score for Code Review.
|
||||
Because the negative sign is required, the = operator is optional.
|
||||
|
||||
`label:CodeReview=1`::
|
||||
+
|
||||
Matches changes where there is at least one +1 score for Code Review.
|
||||
Scores of +2 are not matched, even though they are higher.
|
||||
|
||||
`label:CodeReview>=1`::
|
||||
+
|
||||
Matches changes with either a +1, +2, or any higher score.
|
||||
|
||||
`label:CodeReview<=-1`::
|
||||
+
|
||||
Matches changes with either a -1, -2, or any lower score.
|
||||
|
||||
`is:open CodeReview+2 Verified+1 -Verified-1 -CodeReview-2`::
|
||||
+
|
||||
Matches changes that are ready to be submitted.
|
||||
|
||||
`is:open (Verified-1 OR CodeReview-2)`::
|
||||
+
|
||||
Changes that are blocked from submission due to a blocking score.
|
||||
|
||||
|
||||
Magical Operators
|
||||
-----------------
|
||||
|
||||
Most of these operators exist to support features of Gerrit Code
|
||||
Review, and are not meant to be accessed by the average end-user.
|
||||
However, they are recognized by the query parser, and may prove
|
||||
useful in limited contexts to administrators or power-users.
|
||||
|
||||
visibleto:'USER-or-GROUP'::
|
||||
+
|
||||
Matches changes that are visible to 'USER' or to anyone who is a
|
||||
member of 'GROUP'. Here group names may be specified as either
|
||||
an internal group name, or if LDAP is being used, an external LDAP
|
||||
group name. The value may be wrapped in double quotes to include
|
||||
spaces or other special characters. For example, to match an LDAP
|
||||
group: `visibleto:"CN=Developers, DC=example, DC=com"`.
|
||||
+
|
||||
This operator may be useful to test access control rules, however a
|
||||
change can only be matched if both the current user and the supplied
|
||||
user or group can see it. This is due to the implicit 'is:visible'
|
||||
clause that is always added by the server.
|
||||
|
||||
is:visible::
|
||||
+
|
||||
Magical internal flag to prove the current user has access to read
|
||||
the change. This flag is always added to any query.
|
||||
|
||||
starredby:'USER'::
|
||||
+
|
||||
Matches changes that have been starred by 'USER'.
|
||||
|
||||
watchedby:'USER'::
|
||||
+
|
||||
Matches changes that 'USER' has configured watch filters for.
|
||||
|
||||
draftby:'USER'::
|
||||
+
|
||||
Matches changes that 'USER' has left unpublished drafts on.
|
||||
Since the drafts are unpublished, it is not possible to see the
|
||||
draft text, or even how many drafts there are.
|
||||
|
||||
limit:'CNT'::
|
||||
+
|
||||
Limit the returned results to no more than 'CNT' records. This is
|
||||
automatically set to the page size configured in the current user's
|
||||
preferences. Including it in a web query may lead to unpredictable
|
||||
results with regards to pagination.
|
||||
|
||||
resume_sortkey:'KEY'::
|
||||
+
|
||||
Positions the low level scan routine to start from 'KEY' and
|
||||
continue through changes from this point. This is most often used
|
||||
for paginating result sets. Including this in a web query may lead
|
||||
to unpredictable results.
|
||||
|
||||
sortkey_after:'KEY', sortkey_before:'KEY'::
|
||||
+
|
||||
Restart the low level scan routine from 'KEY'. This is automatically
|
||||
set by the pagination system as the user navigates through results
|
||||
of a query. Including either value in a web query may lead to
|
||||
unpredictable results.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,177 +0,0 @@
|
|||
Gerrit Code Review - Signed-off-by Lines
|
||||
=========================================
|
||||
|
||||
[NOTE]
|
||||
This document was literally taken from link:http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;hb=4e8a2372f9255a1464ef488ed925455f53fbdaa1[linux-2.6 Documentation/SubmittingPatches]
|
||||
and is covered by the GPLv2.
|
||||
|
||||
[[Signed-off-by]]
|
||||
Signed-off-by:
|
||||
--------------
|
||||
|
||||
To improve tracking of who did what, especially with patches that can
|
||||
percolate to their final resting place in the kernel through several
|
||||
layers of maintainers, we've introduced a "sign-off" procedure on
|
||||
patches that are being emailed around.
|
||||
|
||||
The sign-off is a simple line at the end of the explanation for the
|
||||
patch, which certifies that you wrote it or otherwise have the right to
|
||||
pass it on as a open-source patch. The rules are pretty simple: if you
|
||||
can certify the below:
|
||||
|
||||
----
|
||||
Developer's Certificate of Origin 1.1
|
||||
|
||||
By making a contribution to this project, I certify that:
|
||||
|
||||
(a) The contribution was created in whole or in part by me and I
|
||||
have the right to submit it under the open source license
|
||||
indicated in the file; or
|
||||
|
||||
(b) The contribution is based upon previous work that, to the best
|
||||
of my knowledge, is covered under an appropriate open source
|
||||
license and I have the right under that license to submit that
|
||||
work with modifications, whether created in whole or in part
|
||||
by me, under the same open source license (unless I am
|
||||
permitted to submit under a different license), as indicated
|
||||
in the file; or
|
||||
|
||||
(c) The contribution was provided directly to me by some other
|
||||
person who certified (a), (b) or (c) and I have not modified
|
||||
it.
|
||||
|
||||
(d) I understand and agree that this project and the contribution
|
||||
are public and that a record of the contribution (including all
|
||||
personal information I submit with it, including my sign-off) is
|
||||
maintained indefinitely and may be redistributed consistent with
|
||||
this project or the open source license(s) involved.
|
||||
----
|
||||
|
||||
then you just add a line saying
|
||||
|
||||
----
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
----
|
||||
|
||||
using your real name (sorry, no pseudonyms or anonymous contributions.)
|
||||
|
||||
Some people also put extra tags at the end. They'll just be ignored for
|
||||
now, but you can do this to mark internal company procedures or just
|
||||
point out some special detail about the sign-off.
|
||||
|
||||
If you are a subsystem or branch maintainer, sometimes you need to slightly
|
||||
modify patches you receive in order to merge them, because the code is not
|
||||
exactly the same in your tree and the submitters'. If you stick strictly to
|
||||
rule (c), you should ask the submitter to rediff, but this is a totally
|
||||
counter-productive waste of time and energy. Rule (b) allows you to adjust
|
||||
the code, but then it is very impolite to change one submitter's code and
|
||||
make him endorse your bugs. To solve this problem, it is recommended that
|
||||
you add a line between the last Signed-off-by header and yours, indicating
|
||||
the nature of your changes. While there is nothing mandatory about this, it
|
||||
seems like prepending the description with your mail and/or name, all
|
||||
enclosed in square brackets, is noticeable enough to make it obvious that
|
||||
you are responsible for last-minute changes. Example :
|
||||
|
||||
----
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
|
||||
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
|
||||
----
|
||||
|
||||
This practise is particularly helpful if you maintain a stable branch and
|
||||
want at the same time to credit the author, track changes, merge the fix,
|
||||
and protect the submitter from complaints. Note that under no circumstances
|
||||
can you change the author's identity (the From header), as it is the one
|
||||
which appears in the changelog.
|
||||
|
||||
[[Acked-by]]
|
||||
[[Cc]]
|
||||
Acked-by:, Cc:
|
||||
--------------
|
||||
|
||||
The Signed-off-by: tag indicates that the signer was involved in the
|
||||
development of the patch, or that he/she was in the patch's delivery path.
|
||||
|
||||
If a person was not directly involved in the preparation or handling of a
|
||||
patch but wishes to signify and record their approval of it then they can
|
||||
arrange to have an Acked-by: line added to the patch's changelog.
|
||||
|
||||
Acked-by: is often used by the maintainer of the affected code when that
|
||||
maintainer neither contributed to nor forwarded the patch.
|
||||
|
||||
Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
|
||||
has at least reviewed the patch and has indicated acceptance. Hence patch
|
||||
mergers will sometimes manually convert an acker's "yep, looks good to me"
|
||||
into an Acked-by:.
|
||||
|
||||
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
|
||||
For example, if a patch affects multiple subsystems and has an Acked-by: from
|
||||
one subsystem maintainer then this usually indicates acknowledgement of just
|
||||
the part which affects that maintainer's code. Judgement should be used here.
|
||||
When in doubt people should refer to the original discussion in the mailing
|
||||
list archives.
|
||||
|
||||
If a person has had the opportunity to comment on a patch, but has not
|
||||
provided such comments, you may optionally add a "Cc:" tag to the patch.
|
||||
This is the only tag which might be added without an explicit action by the
|
||||
person it names. This tag documents that potentially interested parties
|
||||
have been included in the discussion
|
||||
|
||||
|
||||
[[Reported-by]]
|
||||
[[Tested-by]]
|
||||
[[Reviewed-by]]
|
||||
Reported-by:, Tested-by: and Reviewed-by:
|
||||
-----------------------------------------
|
||||
|
||||
If this patch fixes a problem reported by somebody else, consider adding a
|
||||
Reported-by: tag to credit the reporter for their contribution. Please
|
||||
note that this tag should not be added without the reporter's permission,
|
||||
especially if the problem was not reported in a public forum. That said,
|
||||
if we diligently credit our bug reporters, they will, hopefully, be
|
||||
inspired to help us again in the future.
|
||||
|
||||
A Tested-by: tag indicates that the patch has been successfully tested (in
|
||||
some environment) by the person named. This tag informs maintainers that
|
||||
some testing has been performed, provides a means to locate testers for
|
||||
future patches, and ensures credit for the testers.
|
||||
|
||||
Reviewed-by:, instead, indicates that the patch has been reviewed and found
|
||||
acceptable according to the Reviewer's Statement:
|
||||
|
||||
----
|
||||
Reviewer's statement of oversight
|
||||
|
||||
By offering my Reviewed-by: tag, I state that:
|
||||
|
||||
(a) I have carried out a technical review of this patch to
|
||||
evaluate its appropriateness and readiness for inclusion into
|
||||
the mainline kernel.
|
||||
|
||||
(b) Any problems, concerns, or questions relating to the patch
|
||||
have been communicated back to the submitter. I am satisfied
|
||||
with the submitter's response to my comments.
|
||||
|
||||
(c) While there may be things that could be improved with this
|
||||
submission, I believe that it is, at this time, (1) a
|
||||
worthwhile modification to the kernel, and (2) free of known
|
||||
issues which would argue against its inclusion.
|
||||
|
||||
(d) While I have reviewed the patch and believe it to be sound, I
|
||||
do not (unless explicitly stated elsewhere) make any
|
||||
warranties or guarantees that it will achieve its stated
|
||||
purpose or function properly in any given situation.
|
||||
----
|
||||
|
||||
A Reviewed-by tag is a statement of opinion that the patch is an
|
||||
appropriate modification of the kernel without any remaining serious
|
||||
technical issues. Any interested reviewer (who has done the work) can
|
||||
offer a Reviewed-by tag for a patch. This tag serves to give credit to
|
||||
reviewers and to inform maintainers of the degree of review which has been
|
||||
done on the patch. Reviewed-by: tags, when supplied by reviewers known to
|
||||
understand the subject area and to perform thorough reviews, will normally
|
||||
increase the likelihood of your patch getting into the kernel.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -1,372 +0,0 @@
|
|||
Gerrit Code Review - Uploading Changes
|
||||
======================================
|
||||
|
||||
Gerrit supports three methods of uploading changes:
|
||||
|
||||
* Use `repo upload`, to create changes for review
|
||||
* Use `git push`, to create changes for review
|
||||
* Use `git push`, and bypass code review
|
||||
|
||||
All three methods rely on SSH public key authentication, which must
|
||||
first be configured by the uploading user.
|
||||
|
||||
SSH
|
||||
---
|
||||
|
||||
Each user uploading changes to Gerrit must configure one or more SSH
|
||||
public keys. The per-user SSH key list can be accessed over the web
|
||||
within Gerrit by `Settings`, and then accessing the `SSH Keys` tab.
|
||||
|
||||
[[configure_ssh]]
|
||||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
To register a new SSH key for use with Gerrit, paste the contents of
|
||||
your `id_rsa.pub` or `id_dsa.pub` file into the text box and click
|
||||
the add button. Gerrit only understands SSH version 2 public keys.
|
||||
Keys may be supplied in either the OpenSSH format (key starts with
|
||||
`ssh-rsa` or `ssh-dss`) or the RFC 4716 format (file starts with
|
||||
`---- BEGIN SSH2 PUBLIC KEY ----`).
|
||||
|
||||
Typically SSH keys are stored in your home directory, under `~/.ssh`.
|
||||
If you don't have any keys yet, you can create a new one and protect
|
||||
it with a passphrase:
|
||||
|
||||
====
|
||||
ssh-keygen -t rsa
|
||||
====
|
||||
|
||||
Then copy the content of the public key file onto your clipboard,
|
||||
and paste it into Gerrit's web interface:
|
||||
|
||||
====
|
||||
cat ~/.ssh/id_rsa.pub
|
||||
====
|
||||
|
||||
[TIP]
|
||||
Users who frequently upload changes will also want to consider
|
||||
starting a `ssh-agent`, and adding their private key to the list
|
||||
managed by the agent, to reduce the frequency of entering the
|
||||
key's passphrase. Consult `man ssh-agent`, or your SSH client's
|
||||
documentation, for more details on configuration of the agent
|
||||
process and how to add the private key.
|
||||
|
||||
[[test_ssh]]
|
||||
Testing Connections
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To verify your SSH key is working correctly, try using an SSH client
|
||||
to connect to Gerrit's SSHD port. By default Gerrit is running on
|
||||
port 29418, using the same hostname as the web server:
|
||||
|
||||
====
|
||||
$ ssh -p 29418 sshusername@hostname
|
||||
gerrit: no shell available
|
||||
Connection to hostname closed.
|
||||
====
|
||||
|
||||
In the command above, `sshusername` was configured on the `SSH Keys`
|
||||
tab of the `Settings` screen. If it is not set, propose a name
|
||||
and use `Change Username` to select the name.
|
||||
|
||||
To determine the port number Gerrit is running on, visit the special
|
||||
information URL `http://'hostname'/ssh_info`, and copy the port
|
||||
number from the second field:
|
||||
|
||||
====
|
||||
$ curl http://hostname/ssh_info
|
||||
hostname 29418
|
||||
====
|
||||
|
||||
If you are developing an automated tool to perform uploads to Gerrit,
|
||||
let the user supply the hostname or the web address for Gerrit,
|
||||
and obtain the port number on the fly from the `/ssh_info` URL.
|
||||
The returned output from this URL is always `'hostname' SP 'port'`,
|
||||
or `NOT_AVAILABLE` if the SSHD server is not currently running.
|
||||
|
||||
|
||||
git push
|
||||
--------
|
||||
|
||||
[[push_create]]
|
||||
Create Changes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
To create new changes for review, simply push into the project's
|
||||
magical `refs/for/'branch'` ref using any Git client tool:
|
||||
|
||||
====
|
||||
git push ssh://sshusername@hostname:29418/projectname HEAD:refs/for/branchname
|
||||
====
|
||||
|
||||
E.g. `john.doe` can use git push to upload new changes for the
|
||||
`experimental` branch of project `kernel/common`, hosted at the
|
||||
`git.example.com` Gerrit server:
|
||||
|
||||
====
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental
|
||||
====
|
||||
|
||||
Each new commit uploaded by the `git push` client will be
|
||||
converted into a change record on the server. The remote ref
|
||||
`refs/for/experimental` is not actually created by Gerrit, even
|
||||
though the client's status messages may say otherwise.
|
||||
|
||||
Other users (e.g. project owners) who have configured Gerrit to
|
||||
notify them of new changes will be automatically sent an email
|
||||
message when the push is completed.
|
||||
|
||||
To include a short tag associated with all of the changes in the
|
||||
same group, such as the local topic branch name, append it after
|
||||
the destination branch name. In this example the short topic tag
|
||||
'driver/i42' will be saved on each change this push creates or
|
||||
updates:
|
||||
|
||||
====
|
||||
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/experimental/driver/i42
|
||||
====
|
||||
|
||||
If you are frequently uploading changes to the same Gerrit server,
|
||||
consider adding an SSH host block in `~/.ssh/config` to remember
|
||||
your username, hostname and port number. This permits the use of
|
||||
shorter URLs on the command line, such as:
|
||||
|
||||
====
|
||||
$ cat ~/.ssh/config
|
||||
...
|
||||
Host tr
|
||||
Hostname git.example.com
|
||||
Port 29418
|
||||
User john.doe
|
||||
|
||||
$ git push tr:kernel/common HEAD:refs/for/experimental
|
||||
====
|
||||
|
||||
Specific reviewers can be requested and/or additional ``carbon
|
||||
copies'' of the notification message may be sent by including these
|
||||
as arguments to `git receive-pack`:
|
||||
|
||||
====
|
||||
git push --receive-pack='git receive-pack --reviewer=a@a.com --cc=b@o.com' tr:kernel/common HEAD:refs/for/experimental
|
||||
====
|
||||
|
||||
The `\--reviewer='email'` and `\--cc='email'` options may be
|
||||
specified as many times as necessary to cover all interested
|
||||
parties. Gerrit will automatically avoid sending duplicate email
|
||||
notifications, such as if one of the specified reviewers or CC
|
||||
addresses had also requested to receive all new change notifications.
|
||||
|
||||
If you are frequently sending changes to the same parties and/or
|
||||
branches, consider adding a custom remote block to your project's
|
||||
`.git/config` file:
|
||||
|
||||
====
|
||||
$ cat .git/config
|
||||
...
|
||||
[remote "for-a-exp"]
|
||||
url = tr:kernel/common
|
||||
receivepack = git receive-pack --reviewer=a@a.com --cc=b@o.com
|
||||
push = HEAD:refs/for/experimental
|
||||
|
||||
$ git push for-a-exp
|
||||
====
|
||||
|
||||
|
||||
[[push_replace]]
|
||||
Replace Changes
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
To add an additional patch set to a change, ensure Change-Id
|
||||
lines were created in the original commit messages, and just use
|
||||
`git push URL HEAD:refs/for/...` as <<push_create,described above>>.
|
||||
Gerrit Code Review will automatically match the commits back to
|
||||
their original changes by taking advantage of the Change-Id lines.
|
||||
|
||||
If Change-Id lines are not present in the commit messages, consider
|
||||
amending the message and copying the line from the change's page
|
||||
on the web, and then using `git push` as described above.
|
||||
|
||||
If Change-Id lines are not available, then the user must use the
|
||||
manual mapping technique described below.
|
||||
|
||||
For more about Change-Ids, see link:user-changeid.html[Change-Id Lines].
|
||||
|
||||
[[manual_replacement_mapping]]
|
||||
Manual Replacement Mapping
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.Deprecation Warning
|
||||
****
|
||||
The remainder of this section describes a manual method of replacing
|
||||
changes by matching each commit name to an existing change number.
|
||||
End-users should instead prefer to use Change-Id lines in their
|
||||
commit messages, as the process is then fully automated by Gerrit
|
||||
during normal uploads.
|
||||
|
||||
See above for the preferred technique of replacing changes.
|
||||
****
|
||||
|
||||
To add an additional patch set to a change, replacing it with an
|
||||
updated version of the same logical modification, send the new
|
||||
commit to the change's ref. For example, to add the commit whose
|
||||
SHA-1 starts with `c0ffee` as a new patch set for change number
|
||||
`1979`, use the push refspec `c0ffee:refs/changes/1979` as below:
|
||||
|
||||
====
|
||||
git push ssh://sshusername@hostname:29418/projectname c0ffee:refs/changes/1979
|
||||
====
|
||||
|
||||
This form can be combined together with `refs/for/'branchname'`
|
||||
(above) to simultaneously create new changes and replace changes
|
||||
during one network transaction.
|
||||
|
||||
For example, consider the following sequence of events:
|
||||
|
||||
====
|
||||
$ git commit -m A ; # create 3 commits
|
||||
$ git commit -m B
|
||||
$ git commit -m C
|
||||
|
||||
$ git push ... HEAD:refs/for/master ; # upload for review
|
||||
... A is 1500 ...
|
||||
... B is 1501 ...
|
||||
... C is 1502 ...
|
||||
|
||||
$ git rebase -i HEAD~3 ; # edit "A", insert D before B
|
||||
; # now series is A'-D-B'-C'
|
||||
$ git push ...
|
||||
HEAD:refs/for/master
|
||||
HEAD~3:refs/changes/1500
|
||||
HEAD~1:refs/changes/1501
|
||||
HEAD~0:refs/changes/1502 ; # upload replacements
|
||||
====
|
||||
|
||||
At the final step during the push Gerrit will attach A' as a new
|
||||
patch set on change 1500; B' as a new patch set on change 1501; C'
|
||||
as a new patch set on 1502; and D will be created as a new change.
|
||||
|
||||
Ensuring D is created as a new change requires passing the refspec
|
||||
`HEAD:refs/for/branchname`, otherwise Gerrit will ignore D and
|
||||
won't do anything with it. For this reason it is a good idea to
|
||||
always include the create change refspec when uploading replacements.
|
||||
|
||||
|
||||
[[bypass_review]]
|
||||
Bypass Review
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Changes (and annotated tags) can be pushed directly into a
|
||||
repository, bypassing the review process. This is primarily useful
|
||||
for a project owner to create new branches, create annotated tags
|
||||
for releases, or to force-update a branch whose history needed to
|
||||
be rewritten.
|
||||
|
||||
Gerrit restricts direct pushes that bypass review to:
|
||||
|
||||
* `refs/heads/*`: any branch can be updated, created, deleted,
|
||||
or rewritten by the pusher.
|
||||
* `refs/tags/*`: annotated tag objects pointing to any other type
|
||||
of Git object can be created.
|
||||
|
||||
To push branches, the `Push Branch` project right must be granted
|
||||
to one (or more) of the user's groups. The allowed levels within
|
||||
this category are:
|
||||
|
||||
* Update: Any existing branch can be fast-forwarded to a new commit.
|
||||
This is the safest mode as commits cannot be discarded. Creation
|
||||
of new branches is rejected.
|
||||
* Create: Implies Update, but also allows creation of a new branch
|
||||
if the name does not not already designate an existing branch name.
|
||||
* Delete: Implies Create and Update, but also allows an existing
|
||||
branch to be deleted. Since a force push is effectively a delete
|
||||
followed by a create, but performed atomically on the server and
|
||||
logged, this also permits forced push updates to branches.
|
||||
|
||||
To push annotated tags, the `Push Annotated Tag` project right must
|
||||
be granted to one (or more) of the user's groups. There is only
|
||||
one level of access in this category.
|
||||
|
||||
Project owners may wish to grant themselves `Push Annotated Tag`
|
||||
only at times when a new release is being prepared, and otherwise
|
||||
grant nothing at all. This ensures that accidental pushes don't
|
||||
make undesired changes to the public repository.
|
||||
|
||||
|
||||
repo upload
|
||||
-----------
|
||||
|
||||
repo is a multiple repository management tool, most commonly
|
||||
used by the Android Open Source Project. For more details, see
|
||||
link:http://source.android.com/download/using-repo[using repo].
|
||||
|
||||
[[repo_create]]
|
||||
Create Changes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
To upload changes to a project using `repo`, ensure the manifest's
|
||||
review field has been configured to point to the Gerrit server.
|
||||
Only the hostname or the web address needs to be given in the
|
||||
manifest file. During upload `repo` will automatically determine the
|
||||
correct port number by reading `http://'reviewhostname'/ssh_info`
|
||||
when its invoked.
|
||||
|
||||
Each new commit uploaded by `repo upload` will be converted into
|
||||
a change record on the server. Other users (e.g. project owners)
|
||||
who have configured Gerrit to notify them of new changes will be
|
||||
automatically sent an email message. Additional notifications can
|
||||
be sent through command line options.
|
||||
|
||||
For more details on using `repo upload`, see `repo help upload`.
|
||||
|
||||
[[repo_replace]]
|
||||
Replace Changes
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
To replace changes, ensure Change-Id lines were created in the
|
||||
commit messages, and just use `repo upload` without the `\--replace`
|
||||
command line flag. Gerrit Code Review will automatically match
|
||||
the commits back to their original changes by taking advantage of
|
||||
their Change-Id lines.
|
||||
|
||||
If Change-Id lines are not present in the commit messages, consider
|
||||
amending the message and copying the line from the change's page
|
||||
on the web.
|
||||
|
||||
If Change-Id lines are not available, then the user must use the much
|
||||
more manual mapping technique offered by `repo upload \--replace`.
|
||||
|
||||
For more about Change-Ids, see link:user-changeid.html[Change-Id Lines].
|
||||
|
||||
|
||||
Gritty Details
|
||||
--------------
|
||||
|
||||
As Gerrit implements the entire SSH and Git server stack within its
|
||||
own process space, Gerrit maintains complete control over how the
|
||||
repository is updated, and what responses are sent to the `git push`
|
||||
client invoked by the end-user, or by `repo upload`. This allows
|
||||
Gerrit to provide magical refs, such as `refs/for/\*` for new
|
||||
change submission and `refs/changes/\*` for change replacement.
|
||||
When a push request is received to create a ref in one of these
|
||||
namespaces Gerrit performs its own logic to update the database,
|
||||
and then lies to the client about the result of the operation.
|
||||
A successful result causes the client to believe that Gerrit has
|
||||
created the ref, but in reality Gerrit hasn't created the ref at all.
|
||||
|
||||
By implementing the entire server stack, Gerrit is also able to
|
||||
perform project level access control checks (to verify the end-user
|
||||
is permitted to access a project) prior to advertising the available
|
||||
refs, and potentially leaking information to a snooping client.
|
||||
Clients cannot tell the difference between 'project not found' and
|
||||
'project exists, but access is denied'.
|
||||
|
||||
Gerrit can also ensure users have completed a valid Contributor
|
||||
Agreement prior to accepting any transferred objects, and if an
|
||||
agreement is required, but not completed, it aborts the network
|
||||
connection before data is sent. This ensures that project owners
|
||||
can be certain any object available in their repository has been
|
||||
supplied under at least one valid agreement.
|
||||
|
||||
GERRIT
|
||||
------
|
||||
Part of link:index.html[Gerrit Code Review]
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
opendev/gerrit
|
||||
==============
|
||||
|
||||
THIS PROJECT IS RETIRED. PLEASE SEE THE UPSTREAM PROJECT AT
|
||||
|
||||
https://gerrit.googlesource.com/gerrit/
|
||||
|
||||
This project was retired on 2022-03-16. It was a mirror of the
|
||||
upstream repository with patches for the review.opendev.org service
|
||||
applied.
|
||||
|
||||
The opendev.org project has since moved to a model of building
|
||||
directly from upstream source.
|
||||
|
||||
Archival notes
|
||||
==============
|
||||
|
||||
This repository held the Gerrit source used by the OpenDev (nee
|
||||
OpenStack) project before the migration to Gerrit 3.0.
|
||||
|
||||
The original branches have been removed from this project. However,
|
||||
for archival purposes, the following versions were run in production
|
||||
with the only modifications to upstream as per the merged changes:
|
||||
|
||||
* 2.2.1
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.2.1
|
||||
* 2.3.0
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.3.0
|
||||
* 2.3.0-rc0
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.3.0-rc0
|
||||
* 2.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.4
|
||||
* 2.4.1
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.4.1
|
||||
* 2.4.2
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.4.2
|
||||
* 2.4.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.4.4
|
||||
* 2.8
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.8
|
||||
* 2.8.3
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.8.3
|
||||
* 2.8.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.8.4
|
||||
* 2.9.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.9.4
|
||||
* 2.10.2
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.10.2
|
||||
* 2.11.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.11.4
|
||||
* 2.11.9
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.11.9
|
||||
* 2.13
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13
|
||||
* 2.13.3
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13.3
|
||||
* 2.13.4
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13.4
|
||||
* 2.13.5
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13.5
|
||||
* 2.13.7
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13.7
|
||||
* 2.13.8
|
||||
https://review.opendev.org/q/project:opendev%252Fgerrit+status:merged+branch:openstack%252F2.13.8
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
*.html
|
||||
/.published
|
||||
|
|
@ -1,72 +0,0 @@
|
|||
# Copyright (C) 2010 The Android Open Source Project
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
ASCIIDOC ?= asciidoc
|
||||
ASCIIDOC_EXTRA ?=
|
||||
SVN ?= svn
|
||||
PUB_ROOT ?= https://gerrit.googlecode.com/svn/ReleaseNotes
|
||||
|
||||
DOC_HTML := $(patsubst %.txt,%.html,$(wildcard ReleaseNotes*.txt))
|
||||
COMMIT := $(shell git describe HEAD | sed s/^v//)
|
||||
LOCAL_ROOT := .published
|
||||
PUB_DIR := $(PUB_ROOT)
|
||||
|
||||
all: html
|
||||
|
||||
html: index.html $(DOC_HTML)
|
||||
|
||||
update: html
|
||||
@-rm -rf $(LOCAL_ROOT)
|
||||
@echo "Checking out current release notes"
|
||||
@$(SVN) checkout $(PUB_DIR) $(LOCAL_ROOT)
|
||||
@rm -f $(LOCAL_ROOT)/*.html
|
||||
@cp *.html $(LOCAL_ROOT)
|
||||
@cd $(LOCAL_ROOT) && \
|
||||
r=`$(SVN) status | perl -ne 'print if s/^! *//' ` && \
|
||||
if [ -n "$$r" ]; then $(SVN) rm $$r; fi && \
|
||||
a=`$(SVN) status | perl -ne 'print if s/^\? *//' ` && \
|
||||
if [ -n "$$a" ]; then \
|
||||
$(SVN) add $$a && \
|
||||
$(SVN) propset svn:mime-type text/html $$a ; \
|
||||
fi && \
|
||||
echo "Committing release notes at v$(COMMIT)" && \
|
||||
$(SVN) commit -m "Updated release notes to v$(COMMIT)"
|
||||
@-rm -rf $(LOCAL_ROOT)
|
||||
|
||||
clean:
|
||||
rm -f *.html
|
||||
rm -rf $(LOCAL_ROOT)
|
||||
|
||||
index.html: index.txt
|
||||
@echo FORMAT $@
|
||||
@rm -f $@+ $@
|
||||
@$(ASCIIDOC) --unsafe \
|
||||
-a toc \
|
||||
-b xhtml11 -f asciidoc.conf \
|
||||
$(ASCIIDOC_EXTRA) -o $@+ $<
|
||||
@mv $@+ $@
|
||||
|
||||
$(DOC_HTML): %.html : %.txt
|
||||
@echo FORMAT $@
|
||||
@rm -f $@+ $@
|
||||
@v=$$(echo $< | sed 's/^ReleaseNotes-//;s/.txt$$//;') && \
|
||||
c=$$(git rev-list -1 HEAD -- $<) && \
|
||||
n=$$(git describe $$c) && \
|
||||
if [ "X$$n" != "Xv$$v" ]; then v="$$v (from $$n)"; fi && \
|
||||
$(ASCIIDOC) --unsafe \
|
||||
-a toc \
|
||||
-a "revision=$$v" \
|
||||
-b xhtml11 -f asciidoc.conf \
|
||||
$(ASCIIDOC_EXTRA) -o $@+ $<
|
||||
@mv $@+ $@
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
Release notes for Gerrit 2.0.10
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.10 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
* GERRIT-129 Make the browser window title reflect the current scre...
|
||||
+
|
||||
Useful usability enhancement when you have multiple tabs open.
|
||||
|
||||
* GERRIT-132 Allow binary files to be downloaded from changes for l...
|
||||
+
|
||||
Useful if you need to view say a Microsoft Word document or a PDF.
|
||||
|
||||
* GERRIT-130 Allow publishing comments on non-current patch sets
|
||||
+
|
||||
Now comments can still be published, even if the change owner has uploaded a replacement while you were creating drafts.
|
||||
|
||||
* GERRIT-138 Show the author name in change submitted email notific...
|
||||
+
|
||||
Minor enhancement to the way submitted emails are formatted.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
* GERRIT-91 Delay updating the UI until a Screen instance is fully...
|
||||
+
|
||||
This is a huge UI improvement. Gerrit now waits to display until the data is ready and the UI is updated. Thus you won't see it show stale data, and then suddenly update to
|
||||
whatever you actually clicked on.
|
||||
|
||||
* GERRIT-134 Allow users to preview how Gerrit will format an inlin...
|
||||
+
|
||||
Also a huge usability improvement.
|
||||
|
||||
* Update SSHD to 1.0-r766258_M5
|
||||
+
|
||||
This version of MINA SSHD correctly supports SSH ControlMaster, a trick to reuse SSH connections, supported by repo. See [http://jira.source.android.com/jira/browse/REPO-11 REPO-11].
|
||||
|
||||
* GERRIT-122 Fix too wide SSH Keys table by clipping the server hos...
|
||||
* GERRIT-131 Fix comment editors on the last line of a file
|
||||
* GERRIT-135 Enable Save button after paste in a comment editor
|
||||
* GERRIT-137 Error out if a user forgets to squash when replacing a...
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.10 development
|
||||
* Add missing super.onSign{In,Out} calls to ChangeScreen
|
||||
* Remove the now pointless sign in callback support
|
||||
* Change our site icon to be more git-like
|
||||
* Ensure blank space between subject line and body of co...
|
||||
* Create a debug mode only method of logging in to Gerrit
|
||||
* Refactor UI construction to be more consistent across ...
|
||||
* Do not permit GWT buttons to wrap text
|
||||
* Fix the sign in dialog to prevent line wrapping "Link ...
|
||||
* Change Patch.ChangeType.ADD to be past tense
|
||||
* Improve initial page load by embedding user account da...
|
||||
* Automatically expand inline comment editors for larger...
|
||||
* Merge change 9533
|
||||
* Upgrade MINA SSHD to SVN 761333 and mina-core to 2.0.0...
|
||||
* Use gwtexpui 1.0.4 final
|
||||
* gerrit 2.0.10
|
||||
|
|
@ -1,129 +0,0 @@
|
|||
Release notes for Gerrit 2.0.11
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.11 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
*WARNING: This version contains a schema change.*
|
||||
|
||||
Apply the schema upgrade:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade009_010.sql | psql reviewdb
|
||||
----
|
||||
|
||||
Important Notes
|
||||
---------------
|
||||
|
||||
Cache directory
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Gerrit now prefers having a temporary directory to store a disk-based content cache. This cache used to be in the PostgreSQL database, and was the primary reason for the rather large size of the Gerrit schema. In 2.0.11 the cache has been moved to the local filesystem, and now has automatic expiration management to prevent it from growing too large. As this is only a cache, making backups of this directory is not required.
|
||||
|
||||
It is suggested (but not required) that you enable this cache:
|
||||
----
|
||||
mkdir $site_path/disk_cache
|
||||
chown gerrituser $site_path/disk_cache
|
||||
chmod 700 $site_path/disk_cache ; # just to be paranoid
|
||||
----
|
||||
The directory can also be placed elsewhere in the local filesystem, see `cache.directory` in the `gerrit.config` file.
|
||||
|
||||
link:http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html[http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html]
|
||||
|
||||
Protocol change
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The protocol between the browser based JavaScript and the server has changed. After installing 2.0.11 users need to load the site page again to ensure they are running 2.0.11 or later. Users can verify they have the new version by checking the version number in the footer in the lower right. Users who don't load the new version (e.g. are using a stale tab from a week ago) will see errors when trying to view patches.
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
* GERRIT-8 Add 'Whole File' as a context preference in the user s...
|
||||
* GERRIT-9 Honor user's "Default Context" preference
|
||||
* GERRIT-14 Split patch view RPCs into two halves
|
||||
* GERRIT-61 Database error in side by side view
|
||||
* GERRIT-156 Rewrite the side-by-side and unified diff viewers
|
||||
+
|
||||
The side by side and unified patch viewers have been completely rewritten. Gerrit now honors the user's Default Context setting (from My > Settings) in both the side by side and the unified patch view. A new "Whole File" setting is also available, showing the complete file.
|
||||
|
||||
* GERRIT-154 Add the branch name to the beginning of the subject li...
|
||||
* Sending mail when merge failed due to path conflict, m...
|
||||
+
|
||||
Some improvements have been made with regards to the emails sent by Gerrit.
|
||||
|
||||
* Configure the JGit WindowCache from $site_path/gerrit....
|
||||
* Document the new gerrit.config file
|
||||
+
|
||||
Gerrit now supports a Git-style "$site_path/gerrit.config" configuration file. Currently this supports configuration of the various memory caches, including control over JGit's pack file cache. See the updated documentation section for more details:
|
||||
link:http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html[http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html]
|
||||
|
||||
* Add "gerrit show-caches" to view cache statistics
|
||||
+
|
||||
There is a new administrative command over SSH called "gerrit show-caches" which displays current cache statistics for the various caches within the Gerrit memory space.
|
||||
|
||||
* Expand local part emails when creating new changes
|
||||
+
|
||||
Simple DWIMery: users can now do `repo upload --reviewer=who` to have the reviewer email automatically expand according to the email_format column in system_config, e.g. by expanding `who` to `who@example.com`.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
|
||||
* GERRIT-81 Can't repack a repository while Gerrit is running
|
||||
+
|
||||
Running "git repack", "git gc" or "git fetch" in a repository owned by Gerrit is now safe while Gerrit is running.
|
||||
|
||||
* GERRIT-165 Don't create new user accounts as full name = "null nu...
|
||||
+
|
||||
New users coming from Google Accounts OpenID provider where given a full name of "null null" rather than "Anonymous Coward".
|
||||
|
||||
* Honor account.preferred_email when checking co...
|
||||
+
|
||||
Service users created by manually inserting into the accounts table didn't permit using their preferred_email in commits or tags; administrators had to also insert a dummy record into the account_external_ids table. The dummy account_external_ids record is no longer necessary.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.11 development
|
||||
* Include the 'Google Format' style we selected in our p...
|
||||
* Upgrade JGit to v0.4.0-310-g3da8761
|
||||
* Include JGit sources when building GWT code
|
||||
* Cleanup classpath and use source JARs to build JavaScr...
|
||||
* Remove the ImportGerrit1 command line utility
|
||||
* Remove EncryptContactInfo helper program
|
||||
* Add custom serialization for jgit.diff.Edit
|
||||
* Add Ehcache 1.6.0-beta5 to our dependency list
|
||||
* Start/stop Ehcache when GerritServer starts/stops
|
||||
* Cache OpenID discovery results inside of Ehcache
|
||||
* Cache JGit FileHeader and EditList inside of Ehcache
|
||||
* Store FileHeader and EditList in Ehache during patch s...
|
||||
* Remove the now dead patch_contents table from the data...
|
||||
* Fix "null null" user names during schema upgrade from ...
|
||||
* Work around asciidoc 8.2.2 not including our APLv2 lic...
|
||||
* Remove unused logger from SshServlet
|
||||
* Reuse is administrator test in admin SSH commands
|
||||
* Use common PrintWriter construction in command impleme...
|
||||
* Refactor gerrit flush-caches to just flush everything ...
|
||||
* GERRIT-166 Move the SSH key cache into Ehcache
|
||||
* Change the diff cache serialization of JGit ObjectId i...
|
||||
* Fix git_base_path documentation in config-gerrit
|
||||
* Clarify the default max_session_age in config-gerrit
|
||||
* Enhance the site_path entry in config-gerrit
|
||||
* Clarify the caching of static assets under $site_path/...
|
||||
* Minor grammar fixes in the Google Analytics documentat...
|
||||
* Document that replication honors StrictHostKeyChecking
|
||||
* Document how ~/.ssh/known_hosts is used during replica...
|
||||
* Document how ssh-agent cannot be used for replication
|
||||
* Fix git_base_path references in project-setup
|
||||
* Cleanup project setup documentation
|
||||
* Expand the config-contact documentation to describe th...
|
||||
* Clarify the gitweb integration documentation
|
||||
* Minor corrections in install documentation
|
||||
* Reformat the config-gerrit page to free up section hea...
|
||||
* Enable table of contents in documentation files
|
||||
* Add the source code version number to documentation
|
||||
* More reformatting of the config-gerrit page
|
||||
* Cleanup formatting references for file system path var...
|
||||
* Cleanup the documentation index
|
||||
* Kill the feature roadmap in the documentation
|
||||
* Only use the disk cache directory if we can write to it
|
||||
* Change the title of the installation guide
|
||||
* Note in the developer install guides that you need to ...
|
||||
|
|
@ -1,140 +0,0 @@
|
|||
Release notes for Gerrit 2.0.12
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.12 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
*WARNING: This version contains a schema change.*
|
||||
|
||||
Apply the schema upgrade:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade010_011.sql | psql reviewdb
|
||||
----
|
||||
|
||||
Important Notes
|
||||
---------------
|
||||
|
||||
Java 6 Required
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Gerrit now requires running within a Java 6 (or later) JVM.
|
||||
|
||||
Protocol change
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
The protocol between the browser based JavaScript and the server has changed. After installing 2.0.12 users need to load the site page again to ensure they are running 2.0.12 or later. Users can verify they have the new version by checking the version number in the footer in the lower right. Users who don't load the new version (e.g. are using a stale tab from a week ago) will see errors when trying to view patches.
|
||||
|
||||
New Features
|
||||
------------
|
||||
* Honor --reviewer=not.preferred.email during upload
|
||||
* Also scan by preferred email for --reviewers and --cc ...
|
||||
+
|
||||
Better DWIMery for matching reviewers by name, email address, or just local name (e.g. "jdoe") if using HTTP authentication with email_format.
|
||||
|
||||
* Add support for MySQL database
|
||||
+
|
||||
Now MySQL can be used as a backend data store.
|
||||
|
||||
* Switch all current SSH commands to use args4j
|
||||
* Allow targeted cache flushes to only specific caches
|
||||
+
|
||||
SSH commands, especially administrative ones like "gerrit show-caches", "gerrit flush-caches", or "gerrit show-connections" now accept options like "-h"/"--help" to view command line options, and use a more typical option parsing semantics.
|
||||
|
||||
* GERRIT-164 Bind our SSH daemon with SO_REUSEADDR
|
||||
* Honor sshd.tcpKeepAlive for TCP keep alive controls
|
||||
* Enable SSH daemon cipher and MAC configuration
|
||||
+
|
||||
The SSH daemon now binds with SO_REUSEADDR, making warm-restarts of the daemon easier, especially if the site is busy. Additionally, gerrit.config gained some new options to further control the behavior of the internal SSHD.
|
||||
|
||||
* Add admin command 'gerrit show-connections'
|
||||
+
|
||||
The new "gerrit show-connections" command reports who is connected, from what host, and what command(s) they are running on that SSH session.
|
||||
|
||||
* Replace the top menu bar with a tab panel and links
|
||||
* GERRIT-27 Add a search box to quickly locate changes by change n...
|
||||
+
|
||||
The top menu bar area has been redesigned, and a search box has been added on the right, below the username and Settings links. Currently the search box only accepts change numbers, but in the future we hope to support additional types of query strings.
|
||||
|
||||
* Allow users to disable clippy the flash movie if they ...
|
||||
+
|
||||
A new per-account setting permits users to disable the clippy Flash movie that supports copying text to the clipboard. In every context where this movie appears clicking on the text converts it to a text box, allowing a fast "click Ctrl-C" interaction to place the text on the clipboard. Personally I've found that loading 3 Flash movies on a change page really slowed down the UI rendering, so I wanted to disable the Flash movies.
|
||||
|
||||
* Allow users to control the number of results per page
|
||||
+
|
||||
A new per-account setting allows users to control how many rows appear per page in the All screens, like All Open Changes, etc.
|
||||
|
||||
* Rewrite the keyboard event handlers to use new GlobalK...
|
||||
* GERRIT-136 Implement n/p keys to jump to next/previous diff chunk...
|
||||
* Add keyboard bindings n/p for all change lists to pagi...
|
||||
* Put the "Use '?' for keyboard help" ahead of the versi...
|
||||
* GERRIT-136 Use 'f' in a patch to browse the list of files in the ...
|
||||
* Add global jump navigation keys for the main menu
|
||||
+
|
||||
Keyboard bindings have been completely overhauled in this release, and should now work on every browser. Press '?' in any context to see the available actions. Please note that this help is context sensitive, so you will only see keys that make sense in the current context. Actions in a user dashboard screen differ from actions in a patch (for example), but where possible the same key is used when the logical meaning is unchanged.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Ignore "SshException: Already closed" errors
|
||||
+
|
||||
Hides some non-errors from the log file.
|
||||
|
||||
* GERRIT-86 Stop generating raw #target anchor tags
|
||||
+
|
||||
Should be a minor improvement for MSIE 6 users.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.12 development
|
||||
* Report what version we want on a schema version mismat...
|
||||
* Remove unused imports in SshServlet
|
||||
* Fix vararg warnings in GerritSshDaemon
|
||||
* Update Ehcache to 1.6.0-beta5
|
||||
* Update SSHD to 1.0-r773859
|
||||
* Start targeting Java 1.6
|
||||
* Switch Maven GWT plugin to org.codehaus.mojo:gwt-maven...
|
||||
* GERRIT-75 Upgrade to GWT 1.6.4
|
||||
* GERRIT-75 Switch to GWT 1.6's new HostedMode debugging utility
|
||||
* Allow become any account to use GET parameters
|
||||
* Switch to gwtexpui's new CSS linker module
|
||||
* Load the GWT theme before any other stylesheets
|
||||
* Switch from our own LazyTabChild to GWT 1.6's LazyPanel
|
||||
* GERRIT-75 Convert all GWT 1.5 listener uses to GWT 1.6 handlers
|
||||
* Stop bundling the PostgreSQL driver
|
||||
* Upgrade JGit to 0.4.0-372-gbd3c3db
|
||||
* Add args4j 2.0.12 as a dependency
|
||||
* Describe MySQL and H2 setup in jetty_gerrit.xml templa...
|
||||
* Actually deregister a command when it exits
|
||||
* Put the link to the review inside the body instead of ...
|
||||
* Fix change permalinks after breaking them during GWT 1...
|
||||
* Delete dead CSS bundle code
|
||||
* Always use NpTextBox or NpTextArea to prevent GlobalKe...
|
||||
* Detect cases where system_config has too many rows
|
||||
* Remove unnecessary warning supressions
|
||||
* Remove dead code, these aren't used anymore
|
||||
* Fix warnings about potential serialization problems
|
||||
* Fix warning about debug code in OpenIdServiceImpl
|
||||
* Blur menu item hyperlinks on activation
|
||||
* Fix LinkMenuItem blur on older browsers
|
||||
* Remove dead LoginService, SignInResult classes
|
||||
* Remove pointless GWT.isClient calls in Gerrit module
|
||||
* Refactor how user preferences are applied to the UI
|
||||
* Move the watched project list to its own tab in settin...
|
||||
* Refactor account preferences model
|
||||
* Sort the RSA host key before the DSA host key
|
||||
* Clarify what the "known hosts entry" is
|
||||
* Cleanup the name of the search focus key registration
|
||||
* Change sign out handler to use GWT's HandlerManager su...
|
||||
* Fix all onLoad, onUnload methods to be protected acces...
|
||||
* Honor GWT 1.6's handleAsClick logic in DirectScreenLink
|
||||
* Switch all hyperlinks to be InlineHyperlink
|
||||
* Fix unused import in PatchScreen
|
||||
* Make n/p only honor comments on file adds/deletes
|
||||
* Switch to gwtjsonrpc's new Handler based status update...
|
||||
* Move the comment editor actions into their own keyboar...
|
||||
* Ensure the row pointer is visible before moving it
|
||||
* Automatically reposition/resize file browser if window...
|
||||
* Minor cleanup to Gerrit module bootstrap code path
|
||||
* Make escape in the search box abort the search
|
||||
* Switch to tagged gwtexpui, gwtjsonrpc, gwtorm
|
||||
* gerrit 2.0.12
|
||||
|
|
@ -1,172 +0,0 @@
|
|||
Release notes for Gerrit 2.0.13, 2.0.13.1
|
||||
=========================================
|
||||
|
||||
Gerrit 2.0.13.1 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
*WARNING: This version contains a major configuration change.*
|
||||
|
||||
The schema upgrade needs to run in multiple parts. Apply the first half:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade011_012_part1.sql | psql reviewdb
|
||||
----
|
||||
|
||||
Now convert the system_config table to `$site_path/gerrit.config`.
|
||||
----
|
||||
java -jar gerrit.war ConvertSystemConfig
|
||||
----
|
||||
or, do this conversion by hand. See below for the mapping.
|
||||
|
||||
After verifying `$site_path/gerrit.config` is correct for your installation, drop the old columns from the system_config table. *This causes configuration data loss.*
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade011_012_part2.sql | psql reviewdb
|
||||
----
|
||||
|
||||
Configuration Mapping
|
||||
---------------------
|
||||
|| *system_config* || *$site_path/gerrit.config* ||
|
||||
|| max_session_age || auth.maxSessionAge ||
|
||||
|| canonical_url || gerrit.canonicalWebUrl ||
|
||||
|| gitweb_url || gitweb.url ||
|
||||
|| git_base_path || gerrit.basePath ||
|
||||
|| gerrit_git_name || user.name ||
|
||||
|| gerrit_git_email || user.email ||
|
||||
|| login_type || auth.type ||
|
||||
|| login_http_header || auth.httpHeader ||
|
||||
|| email_format || auth.emailFormat ||
|
||||
|| allow_google_account_upgrade || auth.allowGoogleAccountUpgrade ||
|
||||
|| use_contributor_agreements || auth.contributorAgreements ||
|
||||
|| sshd_port || sshd.listenAddress ||
|
||||
|| use_repo_download || repo.showDownloadCommand ||
|
||||
|| git_daemon_url || gerrit.canonicalGitUrl ||
|
||||
|| contact_store_url || contactstore.url ||
|
||||
|| contact_store_appsec || contactstore.appsec ||
|
||||
|
||||
See also [http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html Gerrit2 Configuration].
|
||||
|
||||
New Features
|
||||
------------
|
||||
* GERRIT-180 Rewrite outgoing email to be more user friendly
|
||||
+
|
||||
A whole slew of feature improvements on outgoing email formatting was closed by this one (massive) rewrite of the outgoing email implementation.
|
||||
|
||||
* GERRIT-187 Make n/p jump to last/first line if no more hunks are ...
|
||||
+
|
||||
When in a patch view (side by side or unified) new key bindings n/p jump to the previous or next hunk, which is very useful if you have context set to Whole File.
|
||||
|
||||
* GERRIT-59 Add Next/Previous/Up links to the PatchScreen
|
||||
+
|
||||
Patch views now contain links to the next and previous file in the patch set, as well as back up to the change. This has been a very long standing UI glitch that is finally resolved.
|
||||
|
||||
* Add "gerrit show-queue" to display the work queue
|
||||
* GERRIT-110 Add admin command "gerrit replicate" to force resync a...
|
||||
* Document all server side command line tools
|
||||
+
|
||||
There are new admin commands available over SSH, and all commands are now documented online. See [http://gerrit.googlecode.com/svn/documentation/2.0/cmd-index.html Command Line Tools]. The new `gerrit replicate` is very useful when a slave goes offline for a bit, and returns later.
|
||||
|
||||
* Add remote.`<`name`>`.replicationdelay to control delay
|
||||
* GERRIT-110 Automatically replicate all projects at startup
|
||||
* GERRIT-110 Allow replication to match only some hosts
|
||||
* GERRIT-200 Schedule replication by remote, not by project
|
||||
+
|
||||
Replication has been made more robust by allowing the administrator to control the delay, as to isolate replication scheduling into different pools. This is very useful when replicating to multiple sites, e.g. to a warm-spare in the same data center, and to a far away slave in another country. Gerrit also now forces a full replication on startup, to ensure all slaves are consistent.
|
||||
|
||||
* Move sshd_port to gerrit.config as sshd.listenaddress
|
||||
+
|
||||
The internal SSHD can now be bound to any IP address/port combinations, which can be useful if the system has multiple virtual IP addresses on a single network interface.
|
||||
|
||||
* Switch from Java Mail to Apache Commons NET basic SMTP...
|
||||
* Block rcpt to addresses not on a whitelist
|
||||
+
|
||||
The new `sendemail` section of `$site_path/gerrit.config` now controls the configuration of the outgoing SMTP server, rather than relying upon a JNDI resource. See [http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html configuration] section sendemail for more details.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Fix file browser in patch that is taller than the wind...
|
||||
* GERRIT-184 Make 'f' toggle the file browser popup closed
|
||||
* GERRIT-188 Fix key bindings in patch when changing the old or new...
|
||||
* GERRIT-211 Remove spurious whitespace from blank lines in diff vi...
|
||||
* GERRIT-196 Fix CSS styling on the history table
|
||||
* GERRIT-193 Automatically switch from empty side-by-side to unifie...
|
||||
+
|
||||
Misc. bug fixes on the patch view screens that I identified after the 2.0.12 release.
|
||||
|
||||
* GERRIT-182 Don't NPE when the remote peer address isn't yet known
|
||||
* GERRIT-192 Fix NPE in MergeOp when submit to new branch fails due...
|
||||
* GERRIT-207 Fix StackOverflowError during cherry-pick submit
|
||||
+
|
||||
Misc. internal bugs, primarily caused by stupid programming mistakes.
|
||||
|
||||
* Invalid sshkeys cache entries when the sshUserName cha...
|
||||
+
|
||||
If a user tried to connect with the wrong user name, then tried to change their SSH User Name through the web UI (by selecting a different preferred email address), the negative cache entry created during their first connection attempt was stuck in the cache and future connections were still rejected. Gerrit now flushes both the old and the new user name cache entries when the user name changes.
|
||||
|
||||
* GERRIT-210 Allow MINA SSHD to log about host key creation
|
||||
* Make SSH host key loading more consistent over time
|
||||
+
|
||||
It has been pointed out several times that its unclear why Gerrit keeps changing its host key with each startup; this is due to a failure to write the generated host key to disk. We now log about it, and make it less likely that other sorts of configuration modifications would cause an unexpected host key change.
|
||||
|
||||
* Always run SSH replication in BatchMode
|
||||
* Special case NoRemoteRepository during replication
|
||||
* Simplify error logged for invalid URLs in replication....
|
||||
* Special case UnknownHostKey during replication
|
||||
* Allow replication.config to drive the thread pool larg...
|
||||
* Fix treatment of symbolic refs in PushOp
|
||||
+
|
||||
A bunch of bug fixes related to error handling during replication. Errors are now logged in a more clear fashion, which should help administrators to debug replication problems.
|
||||
|
||||
* Restore Ctrl-Backspace in comment editor
|
||||
* Use server name for ssh_info instead of local address
|
||||
* Use server name for advertised SSH host keys
|
||||
* Don't reverse resolve CNAMEs when advertising our SSHD
|
||||
+
|
||||
Bug fixes identified after release of 2.0.13, rolled into 2.0.13.1.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.13 development
|
||||
* Use gwtexpui 1.1.1-SNAPSHOT
|
||||
* Document the Patch.PatchType and Patch.ChangeType enum
|
||||
* Document the Change.Status enum
|
||||
* Remove useless boolean return value from ChangeMail he...
|
||||
* Remove pointless null assignment from PatchScreen
|
||||
* Move ChangeMail into its own server side package
|
||||
* Fix patch set replacement emails to correctly retain r...
|
||||
* Document ReviewDb.nextChangeMessageId
|
||||
* Document some of the core database entity graph
|
||||
* Rewrite the replication documentation
|
||||
* Add an anchor for Other Servlet Containers
|
||||
* Fix minor formatting style nit in PushQueue
|
||||
* Extract the PushOp logic from PushQueue
|
||||
* Refactor PushQueue.scheduleUpdate to be smaller methods
|
||||
* Refactor WorkQueue to support task inspection
|
||||
* Reload the submit queue on startup with a 15 second de...
|
||||
* Move the per-command ReviewDb handle up to AbstractCom...
|
||||
* Don't attempt to replicate the magic "-- All Projects ...
|
||||
* Document that remote.<name>.uploadpack is also support...
|
||||
* Correct the defaults for remote uploadpack, receivepack
|
||||
* Use a HashSet for the active tasks, rather than a List
|
||||
* Use gwtorm 1.1.1-SNAPSHOT
|
||||
* Remove references in documentation to My>Settings
|
||||
* Mention 'git receive-pack' --cc/--reviewer args
|
||||
* Fix NPE in "gerrit replicate --all"
|
||||
* Put a link back to the index in every page footer
|
||||
* Document the other standard caches
|
||||
* Delete now unnecessary ImportProjectSubmitTypes
|
||||
* Don't start background queues during command line tools
|
||||
* Create GerritConfig after parsing gerrit.config file
|
||||
* Create a utility to export system_config to gerrit.con...
|
||||
* Move contact store configuration to gerrit.config
|
||||
* Move gerrit_git_email,gerrit_git_name to gerrit.config
|
||||
* Move authentication fields from system_config to gerri...
|
||||
* Move gitwebUrl to gerrit.config
|
||||
* Move use_repo_download to gerrit.config
|
||||
* Move canonical_url, git_daemon_url to gerrit.config
|
||||
* Move git_base_path to gerrit.config
|
||||
* Document where the nextval_project_id function is for ...
|
||||
* Use gwtorm, gwtexpui 1.1.1 final versions
|
||||
* Add sendemail.enable to disable email output
|
||||
* Use mvn -offline mode when running ./to_hosted.sh
|
||||
* Disable AES192CBC and AES256CBC if unlimited cryptogra...
|
||||
* gerrit 2.0.13
|
||||
|
|
@ -1,116 +0,0 @@
|
|||
Release notes for Gerrit 2.0.14, 2.0.14.1
|
||||
=========================================
|
||||
|
||||
Gerrit 2.0.14.1 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
*WARNING: This version contains a schema change* (since 2.0.13)
|
||||
|
||||
Apply the database specific schema script:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade012_013_postgres.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade012_013_mysql.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
New Features
|
||||
------------
|
||||
* GERRIT-177 Display branch name next to project in change list
|
||||
+
|
||||
Now its easier to see from your Mine>Changes what branch each change goes to. For some users this may help prioritize reviews.
|
||||
|
||||
* GERRIT-27 Add commit SHA-1 search to search panel
|
||||
+
|
||||
The search box in the top right now accepts full or abbreviated commit SHA-1s, in addition to change numbers. This is a more user friendly way to locate a change, instead of hacking the URL with the legacy /r/commitsha1 reference.
|
||||
|
||||
* Add "Ignore whitespace" to patch views
|
||||
+
|
||||
You can now ask for a difference ignoring leading/trailing whitespace, which may be useful in a review when a block of code is moved underneath an if, or moved out of an if.
|
||||
|
||||
* Added a checkbox to switch between contextual/full fil...
|
||||
+
|
||||
You can now switch a side-by-side view to full context without going to Settings and returning back.
|
||||
|
||||
* GERRIT-115 Automatically close changes when a commit is pushed in...
|
||||
* GERRIT-54 Close change if a replacement patch set is already sub...
|
||||
+
|
||||
These pair of changes basically mean that if you download and merge a commit locally, then push that directly into a branch (assuming you have been granted Push access), the change closes automatically. Likewise, if a replacement patch set is uploaded to a change, but is already merged to a branch, the change closes automatically. These close some loopholes where the branches and the changes weren't necessarily always in sync.
|
||||
|
||||
* Add a micro scp daemon to our SSHD
|
||||
* Create gerrit-cherry-pick for client usage
|
||||
+
|
||||
Gerrit now runs a micro scp daemon as part of its SSHD, and that scp provides a read-only access of some utility functions for client computers.
|
||||
gerrit-cherry-pick is a small Bourne shell script end-users can scp onto their local system, then use to download and cherry-pick changes from Gerrit by change number.
|
||||
More tools are likely to be developed in the future.
|
||||
|
||||
* Audit group member addition and removals
|
||||
* Add automaticMembership flag to account groups
|
||||
* GERRIT-17 Enable groups to manage contributor agreements
|
||||
+
|
||||
Group membership changes are now audited in the account_group_members_audit table, but the information is not currently published in the web UI. This is a start in the direction of keeping track of "who had access to do what when". In addition, if you use contributor agreements (like review.source.android.com does), CLA acknowledgement can now be done through group membership, rather than a per-user basis.
|
||||
|
||||
* GERRIT-174 Record the submitter in the reflog during merge
|
||||
+
|
||||
This is really for the server admin, the Git reflogs are now more likely to contain actual user information in them, rather than generic "gerrit2@localhost" identities. This may help if you are mining "WTF happened to this branch" data from Git directly.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* GERRIT-213 Fix n/p on a file with only one edit
|
||||
* GERRIT-66 Always show comments in patch views, even if no edit e...
|
||||
* Correctly handle comments after last hunk of patch
|
||||
+
|
||||
Bug fixes for patch views (e.g. side by side and unified). Always showing comments is a really nice plus, it helps during a review to ensure that reviewer comments were addressed, even if there was no edit made in that region of the file.
|
||||
|
||||
* Don't allow commits to replace in wrong project
|
||||
+
|
||||
It was possible to upload a replacement commit in project Foo to a change created in project Bar, putting the Bar change into a corrupt and not-viewable state. This is now correctly error-checked.
|
||||
|
||||
* Update SSHD to 1.0-r784137
|
||||
* GERRIT-199 Update JGit to 0.4.0-388-gd3d9379
|
||||
* Update JGit to 0.4.0-398-ge866578
|
||||
+
|
||||
JGit suffered from some performance problems when the client was very far ahead of the server, e.g. fetching an Android msm kernel (which is based on an older Linux kernel) into a recent bleeding edge kernel repository took hours. It now takes seconds. SSHD was bumped to pick up MINA 2.0.0-M6 which fixes some minor bugs, and is likely to be the final 2.0.0 release version.
|
||||
|
||||
* Fix double click on patch set SHA-1 to select only SHA...
|
||||
* GERRIT-190 Provide feedback when a reviewer is invalid
|
||||
* GERRIT-191 Show email address matched by completion rather than p...
|
||||
+
|
||||
Minor cosmetic improvements.
|
||||
|
||||
* Fix multiple recipient To/CC headers in emails
|
||||
+
|
||||
Fixed run-on addresses when more than one user was listed in To/CC headers.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.14 development (again)
|
||||
* Small doc updates.
|
||||
* Merge change 10282
|
||||
* documentation: Use git config --file path
|
||||
* Skip the ssh:// download URL if the SSHD is unknown
|
||||
* Refactor submitter to PersonIdent mapping in MergeOp
|
||||
* Refactor MergeOp.getSubmitter to return the ChangeAppr...
|
||||
* Remove invalid usage of List.subList(int,int)
|
||||
* Convert command line programs to use args4j
|
||||
* Don't permit overlapping Edit instances in patch scrip...
|
||||
* Merge change 10347
|
||||
* Update executablewar to 1.2
|
||||
* Pass the PatchScriptSettings back as part of the Patch...
|
||||
* Move PatchScriptSettings to .data package
|
||||
* Use ValueChangedHandler for CheckBox update events in ...
|
||||
* Display post-image lines in side-by-side view when ign...
|
||||
* Use binary search when pulling lines from SparseFileCo...
|
||||
* Fix compile error in PatchFile
|
||||
* Don't try to auto-close changes on branch delete
|
||||
* Document the new gerrit-cherry-pick command
|
||||
* gerrit 2.0.14
|
||||
+
|
||||
|
||||
* Start 2.0.15 development
|
||||
* GERRIT-221 Ensure RevCommit's body buffer is available when needed
|
||||
* Fix stack trace capture in Receive error path
|
||||
* Fix --reviewer during replace patch set
|
||||
* Document git receive-pack with Gerrit options
|
||||
* Add toString debugging aids to SparseFileContent
|
||||
* GERRIT-220 Fix bad diff display near empty comment caused edits
|
||||
* gerrit 2.0.14.1
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
Release notes for Gerrit 2.0.15
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.15 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
None. For a change. :-)
|
||||
|
||||
New Features
|
||||
------------
|
||||
* Allow other ignore whitespace settings beyond IGNORE_S...
|
||||
+
|
||||
Now you can ignore whitespace inside the middle of a line, in addition to on the ends.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Update SSHD to include SSHD-28 (deadlock on close) bug...
|
||||
+
|
||||
Fixes a major stability problem with the internal SSHD. Without this patch the daemon can become unresponsive, requiring a complete JVM restart to recover the daemon. The symptom is connections appear to work sporadically... some connections are fine while others freeze during setup, or during data transfer.
|
||||
|
||||
* Fix line-wrapped To/CC email headers
|
||||
+
|
||||
Long To/CC headers with multiple recipients sometimes ran together, making Reply-to-all in the user's email client not address them correctly. This was a bug in the header formatting code, it wasn't RFC 2822 compliant.
|
||||
|
||||
* GERRIT-227 Fix server error when remaining hunks are comments
|
||||
* Fix binary search in SparseFileContent
|
||||
+
|
||||
Stupid bugs in the patch viewing code. Random server errors and/or client UI crashes.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Restart 2.0.15 development
|
||||
* Update JGit to 0.4.0-411-g8076bdb
|
||||
* Remove dead isGerrit method from AbstractGitCommand
|
||||
* Update JSch to 0.1.41
|
||||
* gerrit 2.0.15
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
Release notes for Gerrit 2.0.16
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.16 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
*WARNING: This version contains a schema change* (since 2.0.14)
|
||||
|
||||
Apply the database specific schema script:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade013_014_postgres.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade013_014_mysql.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
New Features
|
||||
------------
|
||||
* Search for changes created or reviewed by a user
|
||||
+
|
||||
The search box in the upper right corner now accepts "owner:email" and "reviewer:email", in addition to change numbers and commit SHA-1s. Using owner: and reviewer: is not the most efficient query plan, as potentially the entire database is scanned. We hope to improve on that as we move to a pure git based backend.
|
||||
|
||||
* Make History panel settings in a diff screen sticky
|
||||
+
|
||||
When comparing different patch sets, e.g. patch set 3 against patch set 2, the settings are now sticky across files in the same change, reducing the number of clicks required to re-review an existing change.
|
||||
|
||||
* GERRIT-113 Permit projects to require Signed-off-by lines to crea...
|
||||
+
|
||||
GERRIT-113 requested that project owners be able to enforce having a Signed-off-by line in the footer of a commit message. Forks of the Linux kernel require this line in order to contribute back upstream. If enabled in the project settings screen there must be a SOB line for the author, the committer, and the uploader of a change (though typically committer == uploader).
|
||||
|
||||
* Use Tested-by: instead of Verified-by: during cherry-p...
|
||||
+
|
||||
The Verified-by footer line created during a cherry-picked submit is now called Tested-by. This better matches with the upstream Linux kernel's conventions of what the role means. Since the kernel is more widespread than Gerrit Code Review, I'm sticking with the kernel's conventions.
|
||||
|
||||
* Extract reviewer suggestions from commit messages
|
||||
+
|
||||
If a commit message contains Reviewed-by, Tested-by or CC footer lines and those email addresses are registered in Gerrit, those users will receive notification of the new change. This is an alternate method to supplying reviewer address on the command line.
|
||||
|
||||
* Drop the unnecessary host page servlet name from URLs
|
||||
+
|
||||
The "/Gerrit" suffix is no longer necessary in the URL. Gerrit now favors just "/" as its path location. This drops one redirection during initial page loading, slightly improving page loading performance, and making all URLs 6 characters shorter. :-)
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Don't create reflogs for patch set refs
|
||||
+
|
||||
Previously Gerrit created pointless 1 record reflogs for each change ref under refs/changes/. These waste an inode on the local filesystem and provide no metadata value, as the same information is also stored in the metadata database. These reflogs are no longer created.
|
||||
|
||||
* Fix "Error out if a user forgets to squash when replac...
|
||||
+
|
||||
Users were still able to find a way to make a change depend upon itself, which makes the change unsubmittable. Often this was done by creating a merge commit, then committing on top of that, and uploading it as a replacement. Gerrit failed to notice this condition because it only considered direct ancestors, now it also looks for indirect ancestors.
|
||||
|
||||
* Fix syntax error in MySQL URL in jetty_gerrit.xml
|
||||
+
|
||||
Someone noticed that the MySQL URL was invalid XML, its fixed now.
|
||||
|
||||
* Catch OpenID errors caused by clock skew and present t...
|
||||
+
|
||||
OpenID errors caused by clock skew (or other factors) now present as an error in the client user interface, and in the server log file, making it more obvious when an OpenID failure occurs. New administrators trying to setup Gerrit installations have often run into problems here, due to bad error reporting.
|
||||
|
||||
* GERRIT-232 Support HTTP connections tunneled through SSH
|
||||
+
|
||||
If the hostname is "localhost" or "127.0.0.1", such as might happen when a user tries to proxy through an SSH tunnel, we honor the hostname anyway if OpenID is not being used.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.16 development
|
||||
* Update JGit to 0.4.9-18-g393ad45
|
||||
* Name replication threads by their remote name
|
||||
* Exclude JGit's JSch version during build
|
||||
* Update ehcache to 1.6.0 release
|
||||
* Update JGit to 0.5.0
|
||||
* Update openid4java to 0.9.5 release
|
||||
* Remove --offline mode from to_hosted.sh
|
||||
* Save all project settings in one RPC
|
||||
* Don't tag Reviewed-by, Tested-by if already Signed-off...
|
||||
* Don't append duplicate Reviewed-on Gerrit URLs during ...
|
||||
* Don't append duplicate Verified-by or Tested-by lines
|
||||
* Use the List<FooterLine> to determine if a paragraph b...
|
||||
* Try harder to pretty-print an exception name in error ...
|
||||
* Fix minor whitespace issues in ErrorDialog
|
||||
* Document how to contribute to Gerrit Code Review
|
||||
* gerrit 2.0.16
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
Release notes for Gerrit 2.0.17
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.17 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
*WARNING: This version contains a schema change* (since 2.0.16)
|
||||
|
||||
Apply the database specific schema script:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade014_015_part1_postgres.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade014_015_part1_mysql.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
After the upgrade is successful, apply the final script to drop dead columns:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade014_015_part2.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade014_015_part2.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
New Features
|
||||
------------
|
||||
* Add '[' and ']' shortcuts to PatchScreen.
|
||||
+
|
||||
The keys '[' and ']' can be used to navigate to previous and next file in a patch set.
|
||||
|
||||
* GERRIT-241 Always show History panel in PatchScreen
|
||||
+
|
||||
The History panel in a patch screen is now always shown, even if there is only one patch set for this file. This permits viewing the number of comments more easily when navigating through files with ']'.
|
||||
|
||||
* Add 'Reply' button to comments on diff screen
|
||||
+
|
||||
There is now a 'Reply' button on the last comment, making it easier to create a new comment to reply to a prior comment on the same line. However, Gerrit still does not quote the prior comment when you reply to it.
|
||||
|
||||
* GERRIT-228 Apply syntax highlighting when showing file content
|
||||
+
|
||||
Files are now syntax highlighted. The following languages are supported, keyed from common file extensions: C (and friends), Java, Python, Bash, SQL, HTML, XML, CSS, JavaScript, and Makefiles.
|
||||
|
||||
* GERRIT-139 Allow mimetype.NAME.safe to enable viewing files
|
||||
+
|
||||
The new configuration option mimetype.NAME.safe can be set to enable unzipped download of a file, for example a Microsoft Word document. See http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html for examples.
|
||||
|
||||
* GERRIT-179 Display images inline for compare if mimetype.image/*....
|
||||
+
|
||||
If mimetype.image/TYPE.safe is true images can be viewed inline in order to more easily visually compare them when an image is modified. Primarily useful for viewing icons in an icon library.
|
||||
|
||||
* File review status tracking.
|
||||
+
|
||||
Per-user green check marks now appear when you view a file. This makes it easier to keep track of which patch set you last looked at, and within a patch set, which files you have looked at, and which ones you have not.
|
||||
|
||||
* GERRIT-247 Allow multiple groups to own a project
|
||||
+
|
||||
The owner of a project was moved from the General tab to the Access Rights tab, under a new category called Owner. This permits multiple groups to be designated the Owner of the project (simply grant Owner status to each group).
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Permit author Signed-off-by to be optional
|
||||
+
|
||||
If a project requires Signed-off-by tags to appear the author tag is now optional, only the committer/uploader must provide a Signed-off-by tag.
|
||||
|
||||
* GERRIT-197 Move 'f' and 'u' navigation to PatchScreen
|
||||
+
|
||||
The 'f' and 'u' keystrokes in a patch screen were disabled when there were no differences to view. This was fixed, they are now always available.
|
||||
|
||||
* Remove annoying 'no differences' error dialog
|
||||
* GERRIT-248 Fix server crash when showing no difference
|
||||
+
|
||||
The "No Differences" error dialog has been removed. Instead the "No Differences" message is displayed in the patch screen. This makes navigation through a pair of patch sets easier with ']' (no dialog stopping to interrupt you when you encounter a file that has not changed and has no comments).
|
||||
|
||||
* GERRIT-244 Always enable Save button on comment editors
|
||||
+
|
||||
Some WebKit based browsers (Apple Safari, Google Chrome) didn't always enable the Save button when selecting a word and deleting it from a comment editor. This is a bug in the browser, it doesn't send an event to the Gerrit UI. As a workaround the Save button is now just always enabled.
|
||||
|
||||
* GERRIT-206 Permit showing changes to gitlinks (aka submodule poin...
|
||||
+
|
||||
You can now view a change made to a gitlink (aka a submodule path).
|
||||
|
||||
* GERRIT-171 Don't crash the submit queue when a change is a criss-...
|
||||
+
|
||||
Instead of crashing on a criss-cross merge case, Gerrit unsubmits the change and attaches a message, like it does when it encounters a path conflict.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Start 2.0.17 development
|
||||
* Move '[' and ']' key bindings to Navigation category
|
||||
* Use gwtexpui 1.1.2-SNAPSHOT to fix navigation keys
|
||||
* A few Javadocs and toString() methods for Patch and Pa...
|
||||
* Merge change 10646
|
||||
* Include the mime-util library to guess file MIME types
|
||||
* Merge change 10667
|
||||
* Added missing access method for accountPatchReviews
|
||||
* Fix bad upgrade014_015 ALTER TABLE command
|
||||
* GERRIT-245 Update PatchBrowserPopup when reviewed status is modif...
|
||||
* Remove DiffCacheContent.isNoDifference
|
||||
* Fix upgrade014_015 part1 scripts WHERE clause
|
||||
* Don't allow users to amend commits made by Gerrit Code...
|
||||
* Fix bad formatting in UnifiedDiffTable appendImgTag
|
||||
* GERRIT-228 Add google-code-prettify 21-May-2009 version
|
||||
* GERRIT-228 Load Google prettify JavaScript into client
|
||||
* Fix formatting errors in PatchScreen
|
||||
* Remove unused imports
|
||||
* GERRIT-250 Fix syntax highlighting of multi-line comments
|
||||
* Use gwtexpui 1.1.2
|
||||
* gerrit 2.0.17
|
||||
|
|
@ -1,317 +0,0 @@
|
|||
Release notes for Gerrit 2.0.18
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.18 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Important Notices
|
||||
-----------------
|
||||
|
||||
Please ensure you read the following important notices about this release; .18 is a much larger release than usual.
|
||||
|
||||
* OpenID Configuration
|
||||
+
|
||||
If you use OpenID authentication, the `trusted_external_ids`
|
||||
table has moved from the database to the local gerrit.config
|
||||
file. Please ensure you copy any critical patterns to the
|
||||
`auth.trustedOpenID` setting in gerrit.config before upgrading
|
||||
your server. Failure to set a pattern will allow Gerrit
|
||||
to trust any OpenID provider. Refer to `auth.trustedOpenID` in
|
||||
[http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html Configuration] for more details.
|
||||
|
||||
* Caches
|
||||
+
|
||||
The groups that a user is a member of is no longer stored in the
|
||||
`groups` cache; it is now part of the `accounts` cache. If you
|
||||
use a cron script to update the `account_groups` database table
|
||||
based upon an external data source (such as LDAP), you will need
|
||||
to adjust your script to flush the `accounts` cache.
|
||||
The `diff` cache is no longer written to disk by default.
|
||||
To enable the disk store again, administrators must explicitly
|
||||
set `cache.directory` in the gerrit.config file prior to starting
|
||||
Gerrit.
|
||||
|
||||
* SSH Usernames
|
||||
+
|
||||
SSH usernames are no longer automatically assigned to the
|
||||
local part of the user's email address. With 2.0.18, usernames
|
||||
must also be unique within the database. These changes were
|
||||
implemented to resolve a minor potential security issue with
|
||||
the SSH authentication system. More details can be found in the
|
||||
[http://android.git.kernel.org/?p=tools/gerrit.git;a=commit;h=080b40f7bbe00ac5fc6f2b10a861b63ce63e8add commit message].
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
*WARNING: This version contains a schema change* (since 2.0.17)
|
||||
|
||||
Important notes about this schema change:
|
||||
|
||||
* The schema change may be difficult to undo once applied.
|
||||
+
|
||||
Downgrading could be very difficult once the upgrade has been started.
|
||||
Going back to 2.0.17 may not be possible.
|
||||
|
||||
* Do not run the schema change while the server is running.
|
||||
+
|
||||
This upgrade changes the primary keys of several tables, an operation
|
||||
which shouldn't occur while end-users are able to make modifications to
|
||||
the database. I _strongly_ suggest a full shutdown, schema upgrade,
|
||||
then startup approach for this release.
|
||||
Apply the database specific schema script:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade015_016_part1_postgres.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade015_016_part1_mysql.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
After the upgrade is successful, apply the final script to drop dead tables:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade015_016_part2.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade015_016_part2.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
New Bugs
|
||||
--------
|
||||
* Memory leaks during warm restarts
|
||||
|
||||
2.0.18 includes [http://code.google.com/p/google-guice/ Google Guice], which leaves a finalizer thread dangling when the Gerrit web application is halted by the servlet container. As this thread does not terminate, the web context stays loaded in memory indefinitely, creating a memory leak. Cold restarting the container in order to restart Gerrit is highly recommended.
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
* GERRIT-104 Allow end-users to select their own SSH username
|
||||
+
|
||||
End users may now select their own SSH username through the web interface. The username must be unique within a Gerrit server installation. During upgrades from 2.0.17 duplicate users are resolved by giving the username to the user who most recently logged in under it; other users will need to login through the web interface and select a unique username. This change was necessary to fix a very minor security bug (see above).
|
||||
|
||||
* Display supported commands when subcommand is not prov...
|
||||
+
|
||||
Running `ssh -p 29418 gerrit.example.com gerrit` now lists the complete set of subcommands recognized by the gerrit top level command. This (slightly) improves discoverability of the remote command execution facilities.
|
||||
|
||||
* Add a Register link in the menu bar when not signed in
|
||||
+
|
||||
The Register link in the top right shows up on OpenID based sites when the user is not yet signed in. This should help discoverability of signing into a Gerrit server to establish your account identity.
|
||||
|
||||
* Combine all initial page data into a single object
|
||||
* Avoid XSRF initialization requests by using one token ...
|
||||
+
|
||||
An initial XSRF token is now sent as part of the initial HTTP request, and used for all subsequent RPCs from that browser. This reduces the initial page load time by cutting out a few round trips that previously were used to bootstrap that XSRF token.
|
||||
|
||||
* Redirect /Gerrit#foo to /#foo on the client side
|
||||
+
|
||||
Gerrit now favors "/#mine" rather than "/Gerrit#mine" for URLs. Older style URLs will be redirected to the newer style automatically, for the foreseeable future.
|
||||
|
||||
* Sort permissions in project access tab
|
||||
* Get branches directly from Git rather than database
|
||||
* Style tab panel headers like our menu bar header
|
||||
* Narrow tables that don't have to be 100% width
|
||||
* Cleanup display of external ids in the user settings
|
||||
+
|
||||
A few minor UI nits in the Settings and Admin panels. The new UI is a bit more consistent with the theme, and formats data in a bit more sane way. Nothing earth shattering.
|
||||
|
||||
* Make disk cache completely optional
|
||||
+
|
||||
As noted above in the section about cache changes, the disk cache is now completely optional.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* GERRIT-5 Remove PatchSetInfo from database and get it always fr...
|
||||
+
|
||||
A very, very old bug. We no longer mirror the commit data into the SQL database, but instead pull it directly from Git when needed. Removing duplicated data simplifies the data store model, something that is important as we shift from a SQL database to a Git backed database.
|
||||
|
||||
* GERRIT-220 Fix infinite loop in PatchScriptBuilder
|
||||
+
|
||||
Under somewhat rare conditions web request threads locked up in an infinite loop while obtaining the data necessary to show a side-by-side or unified patch view to a browser. The loop doesn't allocate any memory, or perform any database requests, but it still ties up a database connection and a servlet container request processing thread indefinitely. We found the bug internally at Google when our Gerrit server load average spiked to 32... and we had no more connections in our database connection pool, which was also sized at a max of 32 handles.
|
||||
|
||||
* Fix Reviewed-On lines to only include the server URL o...
|
||||
+
|
||||
The Reviewed-On lines in cherry-picked commits were duplicating the server URL.
|
||||
|
||||
* Set outgoing email header Content-Transfer-Encoding: 8...
|
||||
+
|
||||
Emails are sent in UTF-8, which may have the high bit set. Thus the transfer encoding must always be set as 8bit, to prevent gateways from potentially discarding the high bits and corrupting the UTF-8 message payload.
|
||||
|
||||
* Ensure OpenID related responses aren't cached by proxi...
|
||||
+
|
||||
Some OpenID related login responses may have sent HTTP headers which were confusing to proxies, potentially allowing a proxy to cache something it should not have cached. The headers were clarified to better denote no caching is permitted.
|
||||
|
||||
* Move ChangeApproval to be a child of PatchSet
|
||||
+
|
||||
The database schema changed, adding `patch_set_id` to the approval object, and renaming the approval table to `patch_set_approvals`. If you have external code writing to this table, uh, sorry, its broken with this release, you'll have to update that code first. :-\
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
|
||||
This release is really massive because the internal code moved from some really ugly static data variables to doing almost everything through Guice injection. Nothing user visible, but code cleanup that needed to occur before we started making additional changes to the system.
|
||||
|
||||
* Start 2.0.18 development
|
||||
* Remove bad import of HostPageServlet
|
||||
* Upgrade GWT to 1.7.0
|
||||
* Update gwt-maven-plugin to 1.1 release
|
||||
* Remove dead gwt-maven repository
|
||||
* Stop including gwt-dev JARs in project classpath
|
||||
* Remove ConvertSystemConfig utility
|
||||
* Update SSHD to 1.0-r798139
|
||||
* Update JGit to 0.5.0-57-g4c5eb17
|
||||
* Replace our RepositoryCache with JGit's RepositoryCache
|
||||
* Make missing project descriptions an empty file
|
||||
* Remove unused imports.
|
||||
* Move all service implementations into server side code
|
||||
* Move RpcConstants out of Common class
|
||||
* Move the CurrentAccountImpl accessor to Gerrit onModul...
|
||||
* Move workflow function access to CategoryFunction class
|
||||
* Move ChangeDetail.load to strictly server side code
|
||||
* Move the workflow package to be strictly server side
|
||||
* Add Guice 2.0 to our dependencies
|
||||
* Switch web.xml to Guice based injection
|
||||
* Use Guice injection to pass GerritServer to HttpServle...
|
||||
* Use Guice to inject GerritServer into RPC backends
|
||||
* Move calls to Common.getSchemaFactory to GerritServer....
|
||||
* Create the EncyptedContactStore during servlet startup
|
||||
* Move OpenID implementation setup to Guice
|
||||
* Remove more Common.getSchemaFactory invocations to dir...
|
||||
* Pass GerritServer down through SSH command factory
|
||||
* Pass GerritServer instance down through the push queue
|
||||
* Use Guice to setup the FileTypeRegistery singleton
|
||||
* Delete unnecessary GerritCacheControlFilter
|
||||
* Remove pointless Srv subclasses of GerritJsonServlet
|
||||
* Refactor FileTypeRegsitery to be an interface
|
||||
* Let Guice inject the ContactStore implementation
|
||||
* Remove dependency on gwtexpui, gwtjsonrpc and gwtorm p...
|
||||
* Use Guice to bring up the SSH daemon and its configura...
|
||||
* Remove unnecessary GerritServer field in Receive comma...
|
||||
* Move PushQueue and ReplicationQueue to singletons mana...
|
||||
* Get rid of the GerritServer static singleton
|
||||
* Provide SchemFactory ReviewDb by Guice and not Gerrit...
|
||||
* Get the SystemConfig from Guice rather than GerritServ...
|
||||
* Merge change 10823
|
||||
* Inject the site path configuration setting directly
|
||||
* Use FileBasedConfig Config rather than RepositoryConfig
|
||||
* Correct copyright dates in SitePath support to be 2009
|
||||
* Load gerrit.config through Guice injection
|
||||
* Refactor outgoing email to be constructed by Guice
|
||||
* Move contact store configuration off GerritServer
|
||||
* Configure Eclipse projects to cleanup trailing whitesp...
|
||||
* Move PatchSetPublishDetail.load() to server side and i...
|
||||
* Hide GerritServer.getGerritConfig and use Guice outsid...
|
||||
* Use Guice to create the per-request GerritCall object
|
||||
* RegisterNewEmailSender is managed by Guice through Ass...
|
||||
* AddReviewerSender class is managed by Guice through As...
|
||||
* Merge change 10856
|
||||
* Merge change 10858
|
||||
* FilebasedConfig requires File pointing at config file ...
|
||||
* CreateChangeSender class is managed by Guice through A...
|
||||
* AbandonedSender is managed by Guice now.
|
||||
* Move RegisterNewEmailSender to servlet module
|
||||
* Move authentication bits out of GerritServer
|
||||
* Update Ehcache to 1.6.1
|
||||
* Move Ehcache construction out of GerritServer to Guice
|
||||
* CommentSender is managed by Guice now.
|
||||
* MergedSender class is managed by Guice now.
|
||||
* MergeFailSender is managed by Guice now.
|
||||
* Make ReplacePatchSetSender managed by Guice.
|
||||
* Refactor MergeOp to use assisted injection
|
||||
* Inject the canonicalweburl rather than using GerritSer...
|
||||
* Use JGit's cached hostname when URL can't give us the ...
|
||||
* Remove use of PatchSetInfoAccess interface in PatchDet...
|
||||
* Merge change 10839
|
||||
* Use member injection for OutgoingEmail related depende...
|
||||
* Fix CanonicalWebUrl when it is null
|
||||
* Inject the Provider GerritCall rather than looking it...
|
||||
* Use assisted injection to create the PushOp instances
|
||||
* Use PatchSetInfoFactory in OutgoingEmail class.
|
||||
* Simplify the setup of assisted injection factories
|
||||
* Inject the WorkQueue via Guice
|
||||
* Fix ProvisionException catch blocks in GerritServletCo...
|
||||
* Move system configuration related code to the server.c...
|
||||
* Move servlets related to UI RPCs into the server.rpc p...
|
||||
* Reduce CreateSchema dependencies to avoid cache
|
||||
* Start injectors in production mode
|
||||
* Isolate SSHD module from web module
|
||||
* Use ServletContext injection to load files from context
|
||||
* Refactor SSH commands into their own package
|
||||
* Support Guice request and session scopes in SSHD
|
||||
* Cleanup CommandFactory to be session aware
|
||||
* Refactor CurrentUser to always be request scoped
|
||||
* Cleanup names of SSH daemon related classes
|
||||
* Refactor command handling to support subcommands in Gu...
|
||||
* Refactor command thread creation logic into BaseCommand
|
||||
* Move command line parsing to BaseCommand
|
||||
* Avoid duplicate singletons
|
||||
* Don't inject fields in providers
|
||||
* Run Gerrit servlet container in PRODUCTION mode
|
||||
* Make database error reporting more predictable from th...
|
||||
* Fix duplicate definition of ReviewDb injection
|
||||
* Cleanup unused imports in client code
|
||||
* Remove unnecessary references to HttpServletRequest
|
||||
* Get HttpServletRequest via injection rather than JsonS...
|
||||
* Get the remote peer address via the @RemotePeer annota...
|
||||
* Move HTTP related classes to an HTTP specific package
|
||||
* Drop ServletName in favor a unique annotation object
|
||||
* Move all URL lookup to the CanonicalUrlProvider
|
||||
* Only load the OpenID servlets if we are using OpenID a...
|
||||
* Make the magic "Become" mode for development a normal ...
|
||||
* Present new users with a registion welcome screen
|
||||
* Fix SSH daemon in web mode to actually have commands
|
||||
* Explicitly bind RemoteJsonService implementations to t...
|
||||
* Use Anchor for become rather than location assignment
|
||||
* Move the become any account form to a real HTML file
|
||||
* Document the DEVELOPMENT_BECOME_ANY_ACCOUNT auth.type ...
|
||||
* Fix upgrade014_015_part1_mysql syntax errors
|
||||
* Merge change 10972
|
||||
* Inject most server references to GerritConfig
|
||||
* Cleanup CacheManagerProvider's construction of the con...
|
||||
* Make DiffCacheEntryFactory package private
|
||||
* Cache account ids by email address key in Ehcache
|
||||
* Rename ReviewDbProvider to ReviewDbDatabaseProvider
|
||||
* Perform per-request cleanup actions at the end of a re...
|
||||
* Refactor ChangeDetailService to use injected database ...
|
||||
* Move ChangeDetailService code to its own package
|
||||
* Refactor ChangeManageService to use the new Handler st...
|
||||
* Refactor SSH commands to use request scoped database h...
|
||||
* Fix docs in BaseCommand
|
||||
* Mark all of BaseServiceImplementation deprecated
|
||||
* Refactor SSH command permission checks to use CurrentU...
|
||||
* Move ProjectCache to server side and rewrite entire pe...
|
||||
* Make existing BaseServiceImplementation use per-reques...
|
||||
* Use Project.NameKey in admin panels rather than Projec...
|
||||
* Change project to use Project.NameKey as the primary k...
|
||||
* Fix sshdAddress in GerritConfig object sent to clients
|
||||
* Rename ProjectCache.invalidate to evict
|
||||
* Rename ChangeDetailModule to ChangeModule
|
||||
* Move account related RPCs to the account package
|
||||
* Move patch RPC stuff to the rpc.patch package
|
||||
* Remove unnecessary injected dependencies from CatServl...
|
||||
* Document why we abuse the GerritCall in HostPageServlet
|
||||
* Create a dummy account if the user account no longer e...
|
||||
* Construct the AgreementInfo only from server code
|
||||
* Merge change 11021
|
||||
* Convert GroupCache to be injected by Guice and stored ...
|
||||
* Remove Common.getAccountId and use Guice injection only
|
||||
* Remove Common.getSchemaFactory
|
||||
* Remove Common.getAccountCache
|
||||
* Consolidate account lookups to the AccountResolver
|
||||
* Rename GerritServerModule to GerritGlobalModule
|
||||
* Rename SshDaemonModule to SshModule
|
||||
* Update documentation on the named caches
|
||||
* Move trusted_external_ids to auth.trustedOpenID
|
||||
* Paper bag fix OutgoingEmail initialization
|
||||
* Paper bag fix submit action
|
||||
* Fix server error 'Array index out of range' on some pa...
|
||||
* Merge branch 'maint'
|
||||
* Move ChangeApproval to be a child of PatchSet
|
||||
* Make #register alone go to the registration form
|
||||
* Enable register new email after saving contact informa...
|
||||
* Bind ApprovalTypes without using GerritConfig
|
||||
* Remove Common class entirely
|
||||
* Catch missing BouncyCastle PGP during contact store cr...
|
||||
* Correct Owner project_rights min_values during upgrade
|
||||
* Unset use_contributor_agreements if agreements are dis...
|
||||
* Sort permissions in project access tab
|
||||
* Get branches directly from Git rather than database
|
||||
* Style tab panel headers like our menu bar header
|
||||
* Narrow tables that don't have to be 100% width
|
||||
* Cleanup display of external ids in the user settings
|
||||
* Preserve negative approvals when replacing patch sets
|
||||
* Use gwtjsonrpc 1.1.1
|
||||
* gerrit 2.0.18
|
||||
|
|
@ -1,381 +0,0 @@
|
|||
Release notes for Gerrit 2.0.19, 2.0.19.1, 2.0.19.2
|
||||
===================================================
|
||||
|
||||
Gerrit 2.0.19.2 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Important Notices
|
||||
-----------------
|
||||
|
||||
* Prior User Sessions
|
||||
+
|
||||
The cookie used to identify a signed-in user has been changed. All users
|
||||
will be automatically signed-out during this upgrade, and will need to
|
||||
sign-in again after the upgrade is complete.
|
||||
Users who try to use a web session from before the upgrade may receive the
|
||||
obtuse error message "Invalid xsrfKey in request". Prior web clients are
|
||||
misinterpreting the error from the server. Users need to sign-out and
|
||||
sign-in again to pick up a new session.
|
||||
This change was necessary to close GERRIT-83, see below.
|
||||
|
||||
* Preserving Sessions Across Restarts
|
||||
+
|
||||
Administrators who wish to preserve user sessions across server restarts must
|
||||
set [http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html#cache.directory cache.directory] in gerrit.config. This allows Gerrit to flush the set
|
||||
of active sessions to disk during shutdown, and load them back during startup.
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
*WARNING: This version contains a schema change* (since 2.0.18)
|
||||
|
||||
Important notes about this schema change:
|
||||
|
||||
* Do not run the schema change while the server is running.
|
||||
+
|
||||
This upgrade adds a new required column to the changes table, something
|
||||
which cannot be done while users are creating records. Like .18, I _strongly_
|
||||
suggest a full shutdown, schema upgrade, then startup approach.
|
||||
Apply the database specific schema script:
|
||||
----
|
||||
java -jar gerrit.war --cat sql/upgrade016_017_postgres.sql | psql reviewdb
|
||||
java -jar gerrit.war --cat sql/upgrade016_017_mysql.sql | mysql reviewdb
|
||||
----
|
||||
|
||||
|
||||
New Features
|
||||
------------
|
||||
* New ssh create-project command
|
||||
+
|
||||
Thanks to Ulrik Sjölin we now have `gerrit create-project`
|
||||
available over SSH, to construct a new repository and database
|
||||
record for a project. Documentation has also been updated to
|
||||
reflect that the command is now available.
|
||||
|
||||
* Be more liberal in accepting Signed-off-by lines
|
||||
+
|
||||
The "Require Signed-off-by line" feature in a project is now
|
||||
more liberal. Gerrit now requires that the commit be signed off
|
||||
by either the author or the committer. This was relaxed because
|
||||
kernel developers often cherry-pick in patches signed off by
|
||||
the author and by Linus Torvalds, but not by the committer who
|
||||
did the backport cherry-pick.
|
||||
|
||||
* Allow cache.name.diskLimit = 0 to disable on disk cache
|
||||
+
|
||||
Setting cache.name.diskLimit to 0 will disable the disk for
|
||||
that cache, even though cache.directory was set. This allows
|
||||
sites to set cache.diff.diskLimit to 0 to avoid caching the diff
|
||||
records on disk, but still allow caching web_sessions to disk,
|
||||
so that live sessions are maintained across server restarts.
|
||||
This is a change in behavior, the prior meaning of diskLimit =
|
||||
0 was "unlimited", which is not very sane given how Ehcache
|
||||
manages the on disk cache files.
|
||||
|
||||
* Allow human-readable units in config.name.maxage
|
||||
+
|
||||
Timeouts for any cache.name.maxAge may now be specified in human
|
||||
readable units, such as "12 days" or "3 hours". The server will
|
||||
automatically convert them to minutes during parsing. If no
|
||||
unit is specified, minutes are assumed, to retain compatibility
|
||||
with prior releases.
|
||||
|
||||
* Add native LDAP support to Gerrit
|
||||
+
|
||||
Gerrit now has native LDAP support. Setting auth.type to
|
||||
HTTP_LDAP and then configuring the handful of ldap properties
|
||||
in gerrit.config will allow Gerrit to load group membership
|
||||
directly from the organization's LDAP server. This replaces
|
||||
the need for the sync-groups script posted in the wiki. See:
|
||||
link:http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html#ldap[http://gerrit.googlecode.com/svn/documentation/2.0/config-gerrit.html#ldap]
|
||||
If you use the sync-groups script from the wiki page, you would
|
||||
also need to delete the group members after upgrading, to remove
|
||||
unnecessary records in your database:
|
||||
{{{
|
||||
DELETE FROM account_group_members
|
||||
WHERE group_id IN (
|
||||
SELECT group_id FROM account_groups
|
||||
WHERE automatic_membership = 'Y');
|
||||
}}}
|
||||
|
||||
* Don't allow users to edit their name if it comes from LDAP
|
||||
+
|
||||
User information loaded from LDAP, such as full name or SSH
|
||||
username, cannot be modified by the end-user. This allows the
|
||||
Gerrit site administrator to require that users conform to the
|
||||
standard information published by the organization's directory
|
||||
service. Updates in LDAP are automatically reflected in Gerrit
|
||||
the next time the user signs-in.
|
||||
|
||||
* Remembers anchor during HTTP logins
|
||||
+
|
||||
When using an HTTP SSO product, clicking on a Gerrit link received
|
||||
out-of-band (e.g. by email or IM) often required clicking the
|
||||
link twice. On the first click Gerrit redirect you to the
|
||||
organization's single-sign-on authentication system, which upon
|
||||
success redirected to your dashboard. The actual target of the
|
||||
link was often lost, so a second click was required.
|
||||
With .19 and later, if the administrator changes the frontend web
|
||||
server to perform authentication only for the /login/ subdirectory
|
||||
of Gerrit, this can be avoided. For example with Apache:
|
||||
----
|
||||
<Location "/login/">
|
||||
AuthType Basic
|
||||
AuthName "Gerrit Code Review"
|
||||
Require valid-user
|
||||
...
|
||||
</Location>
|
||||
----
|
||||
During a request for an arbitrary URL, such as '/#change,42',
|
||||
Gerrit realizes the user is not logged in. Instead of sending an
|
||||
immediate redirect for authentication, Gerrit sends JavaScript
|
||||
to save the target token (the part after the '#' in the URL)
|
||||
by redirecting the user to '/login/change,42'. This enters
|
||||
the secured area, and performs the authentication. When the
|
||||
authenticated user returns to '/login/change,42' Gerrit sends
|
||||
a redirect back to the original URL, '/#change,42'.
|
||||
|
||||
|
||||
* Create check_schema_version during schema creation
|
||||
+
|
||||
Schema upgrades for PostgreSQL now validate that the current
|
||||
schema version matches the expected schema version at the start
|
||||
of the upgrade script. If the schema does not match, the script
|
||||
aborts, although it will spew many errors.
|
||||
|
||||
* Reject disconnected ancestries when creating changes
|
||||
+
|
||||
Uploading commits to a project now requires that the new commits
|
||||
share a common ancestry with the existing commits of that project.
|
||||
This catches and prevents problems caused by a user making a typo
|
||||
in the project name, and inadverently selecting the wrong project.
|
||||
|
||||
* Change-Id tags in commit messages to associate commits
|
||||
+
|
||||
Gerrit now looks for 'Change-Id: I....' in the footer area of a
|
||||
commit message and uses this to identify a change record within
|
||||
the project.
|
||||
If the listed Change-Id has not been seen before, a new change
|
||||
record is created. If the Change-Id is already known, Gerrit
|
||||
updates the change with the new commit. This simplifies updating
|
||||
multiple changes at once, such as might happen when rebasing an
|
||||
entire series of commits that are still being reviewed.
|
||||
A commit-msg hook can be installed to automatically generate
|
||||
these Change-Id lines during initial commit:
|
||||
{{{
|
||||
scp -P 29418 review.example.com:hooks/commit-msg .git/hooks/
|
||||
}}}
|
||||
Using this hook ensures that the Change-Id is predicatable once
|
||||
the commit is uploaded for review.
|
||||
For more details, please see the docs:
|
||||
link:http://gerrit.googlecode.com/svn/documentation/2.0/user-changeid.html[http://gerrit.googlecode.com/svn/documentation/2.0/user-changeid.html]
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* Fix yet another ArrayIndexOutOfBounds during side-by-s...
|
||||
+
|
||||
We found yet another bug with the side-by-side view failing
|
||||
under certain conditions. I think this is the last bug.
|
||||
|
||||
* Apply URL decoding to parameter of /cat/
|
||||
* Fix old image when shown inline in unified diff
|
||||
+
|
||||
Images weren't displaying correctly, even though
|
||||
mimetype.image/png.safe was true in gerrit.config.
|
||||
Turned out to be a problem with the parameter decoding of the
|
||||
/cat/ servlet, as well as the link being generated wrong.
|
||||
|
||||
* Fix high memory usage seen in `gerrit show-caches`
|
||||
+
|
||||
In Gerrit 2.0.18 JGit had a bug where the repository wasn't being
|
||||
reused in memory. This meant that we were constantly reloading
|
||||
the repository data in from disk, so the server was always maxed
|
||||
out at core.packedGitLimit and core.packedGitOpenFiles, as no
|
||||
data was being reused from the cache. Fixed in this release.
|
||||
|
||||
* Fix display of timeouts in `gerrit show-caches`
|
||||
+
|
||||
Timeouts were not always shown correctly, sometimes 12 hours
|
||||
was showing up as 2.5 days, which is completely wrong. Fixed.
|
||||
|
||||
* GERRIT-261 Fix reply button when comment is on the last line
|
||||
+
|
||||
The "Reply" button didn't work if the comment was on the last
|
||||
line of the file, the browser caught an array index out of
|
||||
bounds exception as we walked off the end of the table looking
|
||||
for where to insert the new editor box.
|
||||
|
||||
* GERRIT-83 Make sign-out really invalidate the user's session
|
||||
+
|
||||
The sign-out link now does more than delete the cookie from the
|
||||
user's browser, it also removes the token from the server side.
|
||||
By removing it from the server, we prevent replay attacks where
|
||||
an attacker has observed the user's cookie and then later tries
|
||||
to issue their own requests with the user's cookie. Note that
|
||||
this sort of attack is difficult if SSL is used, as the attacker
|
||||
would have a much more difficult time of sniffing the user's
|
||||
cookie while it was still live.
|
||||
|
||||
* Evict account record after changing SSH username
|
||||
+
|
||||
Changing the SSH username on the web immediately affected the
|
||||
SSH daemon, but the web still showed the old username. This
|
||||
was due to the change operation not flushing the cache that
|
||||
the web code was displaying from. Fixed.
|
||||
|
||||
* Really don't allow commits to replace in wrong project
|
||||
+
|
||||
It was possible for users to upload replacement commits to the
|
||||
wrong project, e.g. uploading a replacement commit to project
|
||||
B while picking a change number from project A. Fixed.
|
||||
|
||||
=Fixes in 2.0.19.1=
|
||||
-------------------
|
||||
|
||||
* Fix NPE during direct push to branch closing a change
|
||||
+
|
||||
Closing changes by pushing their commits directly into the branch didn't
|
||||
always work as expected, due to some data not being initialized correctly.
|
||||
|
||||
* Ignore harmless "Pipe closed" in scp command
|
||||
+
|
||||
scp command on the server side threw exceptions when a client aborted the
|
||||
data transfer. We typically don't care to log such cases.
|
||||
|
||||
* Refactor user lookup during permission checking
|
||||
* GERRIT-264 Fix membership in Registered Users group
|
||||
+
|
||||
Users were not a member of "Registered Users", this was a rather serious
|
||||
bug in the code as it meant many users lost their access rights.
|
||||
|
||||
* GERRIT-265 Correctly catch "Invalid xsrfKey in request" error as ...
|
||||
+
|
||||
Above I mentioned we should handle this error as "Not Signed In", only
|
||||
the pattern match wasn't quite right. Fixed.
|
||||
|
||||
* GERRIT-263 Fix --re=bob to match bob@example.com when using HTTP_LDAP
|
||||
+
|
||||
HTTP_LDAP broke using local usernames to match an account. Fixed.
|
||||
|
||||
=Fixes in 2.0.19.2=
|
||||
-------------------
|
||||
* Don't line wrap project or group names in admin panels
|
||||
+
|
||||
Line wrapping group names like "All Users" when the description column
|
||||
has a very long name in it is ugly.
|
||||
|
||||
* GERRIT-267 Don't add users to a change review if they cannot access
|
||||
+
|
||||
If a user cannot access a change, let the owner know when they try to
|
||||
add the user as a reviewer, or CC them on it.
|
||||
|
||||
* commit-msg: Do not insert Change-Id if the message is ...
|
||||
+
|
||||
The commit-msg hook didn't allow users to abort accidental git commit
|
||||
invocations, as it still modified the file, making git commit think
|
||||
that the end-user wanted to make a commit. Anyone who has a copy of
|
||||
the hook should upgrade to the new hook, if possible.
|
||||
|
||||
* Support recursive queries against LDAP directories
|
||||
* Fix parsing of LDAP search scope properties
|
||||
+
|
||||
As reported on repo-discuss, recursive search is sometimes necessary,
|
||||
and is now the default.
|
||||
|
||||
Removed Features
|
||||
----------------
|
||||
|
||||
* Remove support for /user/email style URLs
|
||||
+
|
||||
I decided to remove this URL, its a pain to support and not
|
||||
discoverable. Its unlikely anyone is really using it, but if
|
||||
they are, they could try using "#q,owner:email,n,z" instead.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
|
||||
* Start 2.0.19 development
|
||||
* Document the Failure and UnloggedFailure classes in Ba...
|
||||
* Merge change 11109
|
||||
* Document gerrit receive-pack is alias for git receive-...
|
||||
* Define a simple query language for Gerrit
|
||||
* Create new projects on remote systems with mkdir -p
|
||||
* Set the GIT_DIR/description file during gerrit create-...
|
||||
* Remove unnecessary toLowerCase calls in AdminCreatePro...
|
||||
* Remove unnecessary exception from AdminCreateProject
|
||||
* Remove unused import from AccountExternalId
|
||||
* Abstract out account creation and simplify sign-on for...
|
||||
* Implement server side sign-out handling
|
||||
* Cleanup private keys in system_config table
|
||||
* Remove dead max_session_age field from system_config
|
||||
* Report 'Invalid xsrfKey' as 'Not Signed In'
|
||||
* Update gerrit flush-caches documentation about web_ses...
|
||||
* Update documentation on cache "web_sessions" configura...
|
||||
* Add getSchemeRest to AccountExternalId
|
||||
* Cleanup ContactStore and WebModule injection
|
||||
* Catch Bouncy Castle Crypto not installed when loading ...
|
||||
* Declare caches in Guice rather than hardcoded in Cache...
|
||||
* Remove old commented out cache configuration code
|
||||
* Don't NPE in SSH keys panel when SSHD is bound to loca...
|
||||
* Don't send users to #register,register,mine
|
||||
* Document the new LDAP support
|
||||
* Cleanup section anchors to be more useful
|
||||
* Put anchors on every configuration variable section
|
||||
* Add missing AOSP copyright header to WebSession
|
||||
* Fix short header lines in gerrit-config.txt
|
||||
* Update documentation about system_config private key f...
|
||||
* Fetch groups from LDAP during user authentication
|
||||
* Actually honor cache.ldap_groups.maxage
|
||||
* Add enum parsing support to ConfigUtil
|
||||
* Rename LoginType to AuthType
|
||||
* Support loading the sshUserName from LDAP
|
||||
* Change ldap.accountDisplayName to ldap.accountFullName
|
||||
* Fix parsing set-to-nothing options in ldap section
|
||||
* Report more friendly errors from gwtjsonrpc
|
||||
* Ensure dialog box displays correctly on network failure
|
||||
* Document how setting LDAP properties disables web UI
|
||||
* Ensure the commit body is parsed before getting the co...
|
||||
* Cleanup more section anchors
|
||||
* Make documentation table of contents anchors human rea...
|
||||
* Remove notes about HTML 5 offline support
|
||||
* Fix typo in LegacyGerritServlet javadoc
|
||||
* Use subList in server side change query code
|
||||
* Remove unsupported /all_unclaimed
|
||||
* Rewrite UrlRewriteFilter in terms of Guice bindings
|
||||
* Create a commit-msg hook to generate Change-Id tags
|
||||
* Add change_key to changes table in database
|
||||
* Allow searching for changes by Change-Id strings
|
||||
* Display the change key, aka Change-ID in the informati...
|
||||
* Display abbreviated change ids in change lists
|
||||
* Change javax.security AccountNotFoundException to NoSu...
|
||||
* Automatically update existing changes during refs/for/...
|
||||
* Automatically close changes when pushing into a branch...
|
||||
* Document the new commit-msg hook supplied by Gerrit
|
||||
* Correct title of "Command Line Tools" documentation pa...
|
||||
* Correct URL example used in Google Analytics Integrati...
|
||||
* Correct comment about customizing categories and caches
|
||||
* Fix formatting of remote.name.timeout section in docum...
|
||||
* Add anchors for remote settings in replication.config ...
|
||||
* Widen the search panel now that Change-Ids are 41 char...
|
||||
* Revert "Ensure dialog box displays correctly on networ...
|
||||
* Allow searches for Change-Ids starting with lowercase ...
|
||||
* Fix line wrapped formatting in ChangeListServiceImpl
|
||||
* Move Change.Key abbreviation to Change.Key class
|
||||
* Format change ids in listing tables with a fixed with ...
|
||||
* Cleanup documentation of the commit-msg hook
|
||||
* Cleanup the command line tool index page
|
||||
* Correct stale documentation section about SSH authenti...
|
||||
* Correct access control documentation about project own...
|
||||
* Quote the current directory when running asciidoc
|
||||
* Move the Default Workflow link into the top of the Use...
|
||||
* Correct formatting of usage in gerrit-cherry-pick docu...
|
||||
* Document how Gerrit uses Change-Id lines
|
||||
* Add Change-Id lines during cherry-pick if not already ...
|
||||
* Fix "no common ancestry" bug
|
||||
* Fix commit-msg hook to handle first lines like "foo: f...
|
||||
* Add a link to Gerrit's project to the top of gerrit-ch...
|
||||
* Add full ASLv2 copyright notice to commit-msg hook
|
||||
* Embed Gerrit's version number into shell scripts copie...
|
||||
* Don't drop max_session_age column in transaction durin...
|
||||
* gerrit 2.0.19
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
Release notes for Gerrit 2.0.2
|
||||
==============================
|
||||
|
||||
Gerrit 2.0.2 is now available for download:
|
||||
|
||||
link:http://code.google.com/p/gerrit/[http://code.google.com/p/gerrit/]
|
||||
|
||||
Important Notes
|
||||
---------------
|
||||
|
||||
Starting with this version, Gerrit is now packaged as a single WAR file.
|
||||
Just download and drop into your webapps directory for easier deployment.
|
||||
The WAR file itself is also executable via "java -jar gerrit.war", so tools
|
||||
like CreateSchema are easier to invoke ("java -jar gerrit.war
|
||||
CreateSchema").
|
||||
|
||||
The following optional 3rd party JARs are not included in the WAR:
|
||||
|
||||
* Bouncy Castle Crypto API
|
||||
* H2 JDBC Driver
|
||||
* c3p0 pooled DataSource
|
||||
+
|
||||
Existing Gerrit administrators either need to change the SSH host key used
|
||||
by their servers, or download the Bouncy Castle Crypto API. The OpenSSH key
|
||||
file format can only be read if Bouncy Castle is available, so you need to
|
||||
install that library to continue using an existing host key. If you are
|
||||
using Jetty, you can download the library (
|
||||
http://www.bouncycastle.org/java.html) to $JETTY_HOME/lib/plus, then restart
|
||||
Jetty.
|
||||
If you use H2 as your database, you will need to download the JDBC driver
|
||||
and insert it into your container's CLASSPATH. But I think all known
|
||||
instances are on PostgreSQL, so this is probably not a concern to anyone.
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
* Trailing whitespace is highlighted in diff views
|
||||
* SSHD upgraded with "faster connection" patch discussed on list
|
||||
* Git reflogs now contain the Gerrit account information of who did the push
|
||||
* Insanely long change subjects are now clipped at 80 characters
|
||||
|
||||
All Changes
|
||||
-----------
|
||||
|
||||
* Switch back to -SNAPSHOT builds
|
||||
* Overhaul our build system to only create a WAR file
|
||||
* Rename top level directory devutil to gerrit1_import
|
||||
* Move appjar contents up one level to normalize our struc...
|
||||
* Refactor the project admin screen into tabs
|
||||
* Move "Publish Comments" before "Submit Patch Set"
|
||||
* Fix to_jetty.sh to account for the WAR not having a scri...
|
||||
* Don't close SSH command streams as MINA SSHD does it for...
|
||||
* Avoid NPE if sign-in goes bad and is missing a token
|
||||
* Describe how to make /ssh_info unprotected for repo
|
||||
* Improve documentation links to Apache SSHD
|
||||
* Fix Documentation Makefile to correctly handle new files
|
||||
* Insert some line breaks to make Documentation/install.tx...
|
||||
* Don't require Bouncy Castle Crypto
|
||||
* Don't require c3p0 or H2 drivers
|
||||
* Show the account id in the user settings screen
|
||||
* Fix log4j.properties to not run in DEBUG
|
||||
* Don't log DEBUG data out of c3p0's SqlUtils class
|
||||
* Fix to_jetty so it doesn't unpack c3p0 from our WAR
|
||||
* Cleanup c3p0 connection pools if used
|
||||
* Yank the mobile specific OpenID login panel
|
||||
* GERRIT-23 Highlight common whitespace errors such as whitespace on...
|
||||
* Fix tabs in Gerrit.css to be 2 spaces
|
||||
* Record the account identity in all reflogs
|
||||
* Don't allow the project name in change tables to wrap
|
||||
* Clip all change subject lines at 80 columns in change ta...
|
||||
* gerrit 2.0.2
|
||||
|
|
@ -1,87 +0,0 @@
|
|||
Release notes for Gerrit 2.0.20
|
||||
===============================
|
||||
|
||||
Gerrit 2.0.20 is now available in the usual location:
|
||||
|
||||
link:http://code.google.com/p/gerrit/downloads/list[http://code.google.com/p/gerrit/downloads/list]
|
||||
|
||||
Schema Change
|
||||
-------------
|
||||
|
||||
A prior bug (GERRIT-262) permitted some invalid data to enter into some databases. Administrators should consider running the following update statement as part of their upgrade to .20 to make any comments which were created with this bug visible:
|
||||
----
|
||||
UPDATE patch_comments SET line_nbr = 1 WHERE line_nbr < 1;
|
||||
----
|
||||
Unfortunately the correct position of the comment has been lost, and the statement above will simply position them on the first line of the file. Fortunately the lost comments were only on the wrong side of an insertion or deletion, and are generally rare. (On my servers only 0.33% of the comments were created like this.)
|
||||
|
||||
New Features
|
||||
------------
|
||||
* New ssh command approve
|
||||
+
|
||||
Patch sets can now be approved remotely via SSH. For more
|
||||
details on this new feature please see the user documentation:
|
||||
link:http://gerrit.googlecode.com/svn/documentation/2.0/cmd-approve.html[http://gerrit.googlecode.com/svn/documentation/2.0/cmd-approve.html]
|
||||
|
||||
* Support changing Google Account identity strings
|
||||
+
|
||||
For various reasons, including but not being limited to server
|
||||
host name changes, the Google Accounts OpenID provider service
|
||||
may change the identity string it returns to users. By setting
|
||||
auth.allowGoogleAccountUpgrade = true in the configuration file
|
||||
administrators may permit automatically updating an existing
|
||||
account with a new identity by matching on the email address.
|
||||
|
||||
Bug Fixes
|
||||
---------
|
||||
* GERRIT-262 Disallow creating comments on line 0
|
||||
+
|
||||
Users were able to create comments in dead regions of a file.
|
||||
That is, if a region was deleted, and thus the left hand side
|
||||
showed red deletion of lines, and the right hand side showed a
|
||||
grey background of nothing, users were able to place a comment on
|
||||
the right hand side in the nothing area. Since this line did not
|
||||
actually exist, the comment was positioned on line 0 of the file.
|
||||
Because line 0 does not exist (lines are numbered 1..n), these
|
||||
comments become hidden and could not be seen, but showed up in
|
||||
the "X comments" counter seen on the Patch History or in the
|
||||
listing of files in a patch set.
|
||||
The UI and RPC layer was fixed to prevent comments on line 0,
|
||||
but existing comments need to be manually moved to a real line.
|
||||
See above for the suggested SQL UPDATE command.
|
||||
|
||||
* Make ID column same font size as rest of table
|
||||
+
|
||||
The font size of the ID column was too small, it is now the
|
||||
same size as the other columns in the table.
|
||||
|
||||
* Fix ALTER INDEX in upgrade015_016_part1_mysql
|
||||
* GERRIT-269 Fix bad change_key creation in upgrade016_017_mysql
|
||||
+
|
||||
MySQL schema upgrade scripts had a few bugs, fixed.
|
||||
|
||||
Other Changes
|
||||
-------------
|
||||
* Restart 2.0.20
|
||||
* Update MINA SSHD to 0.2.0 release
|
||||
* Update args4j to snapshot built from current CVS
|
||||
* Cleanup newCmdLineParser method in BaseCommand
|
||||
* Remove unnecessary throws IOException in ApproveCommand
|
||||
* Cleanup formatting in ApproveCommand
|
||||
* Cleanup assumption of Branch.NameKey parent is Project...
|
||||
* Fix deprecated constructor warning in PatchSetIdHandler
|
||||
* Don't log command line caused failures in flush-caches
|
||||
* Use Guice to create custom arg4j OptionHandler instanc...
|
||||
* gerrit approve: Allow --code-review=+2
|
||||
* gerrit approve: Cleanup invalid patch set error handli...
|
||||
* gerrit approve: Cleanup error reporting for missing ob...
|
||||
* Parse project names through custom args4j OptionHandler
|
||||
* git receive-pack: Use args4j to parse --reviewer and -...
|
||||
* Move args4j handlers to their own package
|
||||
* gerrit approve: Cleanup option parsing to reduce unnec...
|
||||
* gerrit approve: accept commit SHA-1s for approval too
|
||||
* gerrit approve: Allow approving multiple commits at on...
|
||||
* gerrit approve: Add user documentation
|
||||
* Remove unused imports from PatchSetDetailServiceImpl
|
||||
* Only enable auth.allowGoogleAccountUpgrade when auth.t...
|
||||
* Rename loginType to authType
|
||||
* gerrit 2.0.20
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue