Documentation: Various corrections
Correct typos, spelling mistakes, and grammatical errors. Change-Id: I80ec66de7b2228f9ff45a2f06faf576707195758
This commit is contained in:
David Pursehouse
Gustaf Lundh
parent
4d26f3cd62
commit
221d4f6250
@ -23,7 +23,7 @@ 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
|
||||
or any other access controls. In most installations only those
|
||||
users who have direct filesystem and database access would be
|
||||
placed into this group.
|
||||
|
||||
@ -459,7 +459,7 @@ Create reference
|
||||
The create reference category controls whether it is possible to
|
||||
create new references, branches or tags. This implies that the
|
||||
reference must not already exist, it's not a destructive permission
|
||||
in that you can't overwrite or remove any previosuly existing
|
||||
in that you can't overwrite or remove any previously existing
|
||||
references (and also discard any commits in the process).
|
||||
|
||||
It's probably most common to either permit the creation of a single
|
||||
@ -470,7 +470,7 @@ This permission is often given in conjunction with regular push
|
||||
branch permissions, allowing the holder of both to create new branches
|
||||
as well as bypass review for new commits on that branch.
|
||||
|
||||
To push lightweight (non annotated) tags, grant
|
||||
To push lightweight (non-annotated) tags, grant
|
||||
`Create Reference` for reference name `refs/tags/*`, as lightweight
|
||||
tags are implemented just like branches in Git.
|
||||
|
||||
@ -823,7 +823,7 @@ Examples of typical roles in a project
|
||||
|
||||
Below follows a set of typical roles on a server and which access
|
||||
rights these roles typically should be granted. You may see them as
|
||||
general guide lines for a typical way to set up your project on a
|
||||
general guidelines for a typical way to set up your project on a
|
||||
brand new Gerrit instance.
|
||||
|
||||
[[examples_contributor]]
|
||||
@ -906,8 +906,8 @@ submit of the change even if someone else sets `Verify` +1. Depending on the
|
||||
project and how much the CI system can be trusted for accurate results, a
|
||||
blocking label might not be feasible. A recommended alternative is to set the
|
||||
label `Code-review` to -1 instead, as it isn't a blocking label but still
|
||||
shows a red label in the Gerrit UI. Optionally; to enable the possibility to
|
||||
deliver different results (build error vs unstable for instance) it's also
|
||||
shows a red label in the Gerrit UI. Optionally, to enable the possibility to
|
||||
deliver different results (build error vs unstable for instance), it's also
|
||||
possible to set `Code-review` +1 as well.
|
||||
|
||||
If pushing new changes is granted, it's possible to automate cherry-pick of
|
||||
|
||||
@ -54,7 +54,7 @@ change viewed on the web.
|
||||
OBTAINING
|
||||
---------
|
||||
To obtain the 'commit-msg' script use scp, wget or curl to download it
|
||||
to your local system from your gerrit server.
|
||||
to your local system from your Gerrit server.
|
||||
|
||||
You can use either of the below commands:
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ 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
|
||||
Choose 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.
|
||||
|
||||
|
||||
@ -107,7 +107,7 @@ member of available as groups in Gerrit.
|
||||
* `CLIENT_SSL_CERT_LDAP`
|
||||
+
|
||||
This authentication type is actually kind of SSO. Gerrit will configure
|
||||
Jetty's SSL channel to request client's SSL certificate. For this
|
||||
Jetty's SSL channel to request the client's SSL certificate. For this
|
||||
authentication to work a Gerrit administrator has to import the root
|
||||
certificate of the trust chain used to issue the client's certificate
|
||||
into the <review-site>/etc/keystore.
|
||||
@ -161,7 +161,7 @@ By default, OpenID.
|
||||
+
|
||||
List of permitted OpenID providers. A user may only authenticate
|
||||
with an OpenID that matches this list. Only used if `auth.type`
|
||||
was set to OpenID (the default).
|
||||
is set to OpenID (the default).
|
||||
+
|
||||
Patterns may be either a
|
||||
link:http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html[standard
|
||||
@ -173,7 +173,7 @@ allowing users to authenticate with any OpenID provider.
|
||||
|
||||
[[auth.trustedOpenID]]auth.trustedOpenID::
|
||||
+
|
||||
List of trusted OpenID providers. Only used if `auth.type` was
|
||||
List of trusted OpenID providers. Only used if `auth.type` is
|
||||
set to OpenID (the default).
|
||||
+
|
||||
In order for a user to take advantage of permissions beyond those
|
||||
@ -232,7 +232,7 @@ Default is 12 hours.
|
||||
[[auth.httpHeader]]auth.httpHeader::
|
||||
+
|
||||
HTTP header to trust the username from, or unset to select HTTP basic
|
||||
or digest authentication. Only used if `auth.type` was set to HTTP.
|
||||
or digest authentication. Only used if `auth.type` is set to HTTP.
|
||||
|
||||
[[auth.logoutUrl]]auth.logoutUrl::
|
||||
+
|
||||
@ -513,7 +513,7 @@ within Gerrit, so the cache expire time is largely irrelevant.
|
||||
|
||||
cache `"permission_sort"`::
|
||||
+
|
||||
Caches the order access control sections must be applied to a
|
||||
Caches the order in which access control sections must be applied to a
|
||||
reference. Sorting the sections can be expensive when regular
|
||||
expressions are used, so this cache remembers the ordering for
|
||||
each branch.
|
||||
@ -570,7 +570,7 @@ cache.diff_intraline.maxIdleWorkers::
|
||||
Number of idle worker threads to maintain for the intraline difference
|
||||
computations. There is no upper bound on how many concurrent requests
|
||||
can occur at once, if additional threads are started to handle a peak
|
||||
load, only this many will remaining idle afterwards.
|
||||
load, only this many will remain idle afterwards.
|
||||
+
|
||||
Default is 1.5x number of available CPUs.
|
||||
|
||||
@ -646,7 +646,7 @@ will match typical Gerrit Change-Id values and create a hyperlink
|
||||
to changes which reference it. The second configuration 'bugzilla'
|
||||
will hyperlink terms such as 'bug 42' to an external bug tracker,
|
||||
supplying the argument record number '42' for display. The third
|
||||
configuration 'tracker' uses raw HTML to more preciously control
|
||||
configuration 'tracker' uses raw HTML to more precisely control
|
||||
how the replacement is displayed to the user.
|
||||
|
||||
----
|
||||
@ -1318,7 +1318,7 @@ By default, `$site_path/etc/keystore`.
|
||||
[[httpd.sslKeyPassword]]httpd.sslKeyPassword::
|
||||
+
|
||||
Password used to decrypt the private portion of the sslKeyStore.
|
||||
Java key stores require a password, even if the administrator
|
||||
Java keystores require a password, even if the administrator
|
||||
doesn't want to enable one.
|
||||
+
|
||||
If set to the empty string the embedded server will prompt for the
|
||||
@ -1338,7 +1338,7 @@ and false if httpd.listenUrl uses proxy-http:// or proxy-https://.
|
||||
[[httpd.acceptorThreads]]httpd.acceptorThreads::
|
||||
+
|
||||
Number of worker threads dedicated to accepting new incoming TCP
|
||||
connections and allocate them connection-specific resources.
|
||||
connections and allocating them connection-specific resources.
|
||||
+
|
||||
By default, 2, which should be suitable for most high-traffic sites.
|
||||
|
||||
@ -1366,7 +1366,7 @@ By default 50.
|
||||
|
||||
[[httpd.maxWait]]httpd.maxWait::
|
||||
+
|
||||
Maximum amount of time a client will wait to for an available
|
||||
Maximum amount of time a client will wait for an available
|
||||
thread to handle a project clone, fetch or push request over the
|
||||
smart HTTP transport.
|
||||
+
|
||||
@ -1391,7 +1391,7 @@ By default, 5 minutes.
|
||||
[[ldap]]Section ldap
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
LDAP integration is only enabled if `auth.type` was set to
|
||||
LDAP integration is only enabled if `auth.type` is set to
|
||||
`HTTP_LDAP`, `LDAP` or `CLIENT_SSL_CERT_LDAP`. See above for a
|
||||
detailed description of the auth.type settings and their
|
||||
implications.
|
||||
@ -1459,7 +1459,7 @@ By default, `ignore`.
|
||||
_(Optional)_ The read timeout for an LDAP operation. The value is
|
||||
in the usual time-unit format like "1 s", "100 ms", etc...
|
||||
A timeout can be used to avoid blocking all of the SSH command start
|
||||
threads in case when the LDAP server becomes slow.
|
||||
threads in case the LDAP server becomes slow.
|
||||
+
|
||||
By default there is no timeout and Gerrit will wait for the LDAP
|
||||
server to respond until the TCP connection times out.
|
||||
@ -1506,8 +1506,8 @@ contains the initial value for the user's full name field in Gerrit.
|
||||
Typically this is the `displayName` property in LDAP, but could
|
||||
also be `legalName` or `cn`.
|
||||
+
|
||||
Attribute values may be concatenated with literal strings, for
|
||||
example to join given name and surname together use the pattern
|
||||
Attribute values may be concatenated with literal strings. For
|
||||
example to join given name and surname together, use the pattern
|
||||
`${givenName} ${SN}`.
|
||||
+
|
||||
If set, users will be unable to modify their full name field, as
|
||||
@ -1528,7 +1528,7 @@ of sAMAccountName followed by a constant domain name, use
|
||||
`${sAMAccountName.toLowerCase}@example.com`.
|
||||
+
|
||||
If set, the preferred email address will be prefilled from LDAP,
|
||||
but users may still be able to register additional email address,
|
||||
but users may still be able to register additional email addresses,
|
||||
and select a different preferred email address.
|
||||
+
|
||||
Default is `mail`.
|
||||
@ -1618,7 +1618,7 @@ can be achieved.
|
||||
+
|
||||
If set, it must be ensured that the local usernames for all existing
|
||||
accounts are converted to lower case, otherwise a user that has a
|
||||
local username that contains upper case characters cannot login
|
||||
local username that contains upper case characters will not be able to login
|
||||
anymore. The local usernames for the existing accounts can be
|
||||
converted to lower case by running the server program
|
||||
link:pgm-LocalUsernamesToLowerCase.html[LocalUsernamesToLowerCase].
|
||||
@ -1728,7 +1728,7 @@ If an object is larger than the given size the pack-parsing will abort
|
||||
and the push operation will fail. If set to zero then there is no
|
||||
limit.
|
||||
+
|
||||
Gerrit administrator can use this setting to prevent developers
|
||||
Gerrit administrators can use this setting to prevent developers
|
||||
from pushing objects which are too large to Gerrit.
|
||||
+
|
||||
Default is zero.
|
||||
@ -1995,7 +1995,7 @@ By default, true.
|
||||
+
|
||||
Number of threads to use when executing SSH command requests.
|
||||
If additional requests are received while all threads are busy they
|
||||
are queued and serviced in a first-come-first-serve order.
|
||||
are queued and serviced in a first-come-first-served order.
|
||||
+
|
||||
By default, 1.5x the number of CPUs available to the JVM.
|
||||
|
||||
@ -2062,7 +2062,7 @@ By default, 2 minutes.
|
||||
+
|
||||
Maximum number of concurrent SSH sessions that a user account
|
||||
may open at one time. This is the number of distinct SSH logins
|
||||
the each user may have active at one time, and is not related to
|
||||
that each user may have active at one time, and is not related to
|
||||
the number of commands a user may issue over a single connection.
|
||||
If set to 0, there is no limit.
|
||||
+
|
||||
@ -2210,7 +2210,7 @@ Java regular expression (java.util.regex)] used to match the
|
||||
external tracking id part of the footer line. The match can
|
||||
result in several entries in the DB. If grouping is used in the
|
||||
regex the first group will be interpreted as the tracking id.
|
||||
Tracking ids > 20 char will be ignored.
|
||||
Tracking ids longer than 20 characters will be ignored.
|
||||
+
|
||||
The configuration file parser eats one level of backslashes, so the
|
||||
character class `\s` requires `\\s` in the configuration file. The
|
||||
@ -2219,7 +2219,7 @@ expression containing # must be wrapped in double quotes.
|
||||
|
||||
[[trackingid.name.system]]trackingid.<name>.system::
|
||||
+
|
||||
The name of the external tracking system(max 10 char).
|
||||
The name of the external tracking system (maximum 10 characters).
|
||||
It is possible to have several trackingid entries for the same
|
||||
tracking system.
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ Linux distributions.
|
||||
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.
|
||||
for serving gitweb under a different URL than the Gerrit instance.
|
||||
To enable this feature, set both: `gitweb.cgi` and `gitweb.url`.
|
||||
|
||||
====
|
||||
|
||||
@ -42,7 +42,7 @@ 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
|
||||
To simplify security management, files are only 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`
|
||||
|
||||
@ -88,7 +88,7 @@ Called whenever a user signs a contributor license agreement
|
||||
Configuration Settings
|
||||
----------------------
|
||||
|
||||
It is possible to change where gerrit looks for hooks, and what
|
||||
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
|
||||
|
||||
@ -20,7 +20,7 @@ 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
|
||||
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.)
|
||||
@ -36,7 +36,7 @@ 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)`.
|
||||
text that will be appended to emails related to changes (all `ChangeEmail`s).
|
||||
|
||||
ChangeSubject.vm
|
||||
~~~~~~~~~~~~~~~~
|
||||
@ -49,6 +49,7 @@ 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
|
||||
`ChangeSubject.vm` and `ChangeFooter.vm`.
|
||||
|
||||
Merged.vm
|
||||
~~~~~~~~~
|
||||
@ -62,6 +63,7 @@ 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
|
||||
`ChangeEmail`: see `ChangeSubject.vm` and `ChangeFooter.vm`.
|
||||
|
||||
NewChange.vm
|
||||
~~~~~~~~~~~~
|
||||
@ -107,7 +109,7 @@ 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
|
||||
Be aware that modifying templates can cause them to fail to parse and therefore
|
||||
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.
|
||||
@ -125,7 +127,7 @@ or the current child class inherited from it.
|
||||
|
||||
$messageClass::
|
||||
+
|
||||
A String containing the messageClass
|
||||
A String containing the messageClass.
|
||||
|
||||
$StringUtils::
|
||||
+
|
||||
@ -139,35 +141,35 @@ All change related emails have the following additional variables available to t
|
||||
|
||||
$change::
|
||||
+
|
||||
A reference to the current `Change` object
|
||||
A reference to the current `Change` object.
|
||||
|
||||
$changeId::
|
||||
+
|
||||
Id of the current change (a `Change.Key`)
|
||||
Id of the current change (a `Change.Key`).
|
||||
|
||||
$coverLetter::
|
||||
+
|
||||
The text of the `ChangeMessage`
|
||||
The text of the `ChangeMessage`.
|
||||
|
||||
$branch::
|
||||
+
|
||||
A reference to the branch of this change (a `Branch.NameKey`)
|
||||
A reference to the branch of this change (a `Branch.NameKey`).
|
||||
|
||||
$fromName::
|
||||
+
|
||||
The name of the from user
|
||||
The name of the from user.
|
||||
|
||||
$projectName::
|
||||
+
|
||||
The name of this change's project
|
||||
The name of this change's project.
|
||||
|
||||
$patchSet::
|
||||
+
|
||||
A reference to the current `PatchSet`
|
||||
A reference to the current `PatchSet`.
|
||||
|
||||
$patchSetInfo::
|
||||
+
|
||||
A reference to the current `PatchSetInfo`
|
||||
A reference to the current `PatchSetInfo`.
|
||||
|
||||
|
||||
See Also
|
||||
|
||||
@ -5,7 +5,7 @@ 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
|
||||
This allows the other web server to bind to the privileged port 80
|
||||
(or 443 for SSL), as well as offloads the SSL processing overhead
|
||||
from Java to optimized native C code.
|
||||
|
||||
|
||||
@ -146,7 +146,7 @@ To enable this form of authentication:
|
||||
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
|
||||
The auth.httpHeader indicates in 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.
|
||||
|
||||
@ -37,7 +37,7 @@ 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
|
||||
inherent 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,
|
||||
|
||||
@ -192,7 +192,7 @@ because Status=Submitted is considered a closed issue.
|
||||
Mailing List
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* Send an email to the mailing list to annouce the release
|
||||
* Send an email to the mailing list to announce the release
|
||||
* Consider including some or all of the following in the email:
|
||||
** A link to the release and the release notes (if a final release)
|
||||
** A link to the docs
|
||||
|
||||
@ -7,8 +7,8 @@ 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'.
|
||||
If you specify a non-existing branch in the `refs/for/'branch'` ref
|
||||
the push fails with the error message 'branch ... not found'.
|
||||
|
||||
To fix this problem verify
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ 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
|
||||
recommended 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
|
||||
|
||||
@ -7,7 +7,7 @@ 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
|
||||
explained link:user-upload.html#manual_replacement_mapping[here]. It is recommended to only rely on Change-IDs for
|
||||
link:user-upload.html#push_replace[replacing changes].
|
||||
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ 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].
|
||||
It is recommended to only rely on Change-IDs for link:user-upload.html#push_replace[replacing changes].
|
||||
|
||||
|
||||
GERRIT
|
||||
|
||||
@ -2,10 +2,10 @@ 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
|
||||
patch set for a change, if the pushed commit is identical to the
|
||||
current patch set of this change.
|
||||
|
||||
A pushed commit is considered to be identical with the current patch
|
||||
A pushed commit is considered to be identical to the current patch
|
||||
set if
|
||||
|
||||
- the files in the commit,
|
||||
|
||||
@ -3,7 +3,7 @@ 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.
|
||||
is no new change and consequently there is nothing for Gerrit to do.
|
||||
|
||||
If your push is failing with this error message, you normally
|
||||
don't have to do anything since the commit was already successfully
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
non-fast forward
|
||||
================
|
||||
|
||||
With this error message Git rejects a push if the remote branch can't
|
||||
With this error message Gerrit 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.
|
||||
have based their work on such a commit. Because of this Git by
|
||||
default does not allow non-fast forward updates.
|
||||
|
||||
When working with Gerrit, this error can only occur if
|
||||
link:user-upload.html#bypass_review[code review is bypassed].
|
||||
@ -46,7 +46,7 @@ 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
|
||||
Although it is considered 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
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Not a Gerrit administrator
|
||||
==========================
|
||||
|
||||
With this error message Gerrit rejects to execute a SSH command that
|
||||
With this error message Gerrit rejects to execute an SSH command that
|
||||
requires administrator privileges if the user is not a Gerrit
|
||||
administrator.
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ If you are facing this problem, do the following:
|
||||
project is listed. If the project is not listed the project either
|
||||
does not exist or you don't have
|
||||
link:access-control.html#category_read['Read'] access for it. This
|
||||
means if you certain that the project name is right you should
|
||||
means if you are certain that the project name is right you should
|
||||
contact the Gerrit Administrator or project owner to request access
|
||||
to the project.
|
||||
|
||||
|
||||
@ -2,11 +2,11 @@ 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
|
||||
pushing user has no permission 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 permissions to upload merge commits
|
||||
project owners and request permission to upload merge commits
|
||||
(access right link:access-control.html#category_push_merge['Push Merge Commit'])
|
||||
for this project.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Permission denied (publickey)
|
||||
=============================
|
||||
|
||||
With this error message a SSH command to Gerrit is rejected if the
|
||||
With this error message an 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.
|
||||
|
||||
@ -20,7 +20,7 @@ In particular this error occurs:
|
||||
4. if you push a lightweight tag without the access right link:access-control.html#category_create['Create
|
||||
Reference'] for the reference name 'refs/tags/*'
|
||||
|
||||
For new users it happens often that they accidentally try to bypass
|
||||
For new users it often happens 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/*
|
||||
|
||||
@ -3,7 +3,7 @@ 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.
|
||||
the problem can often 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
|
||||
|
||||
@ -9,7 +9,7 @@ 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.
|
||||
latest one depends 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
|
||||
@ -93,8 +93,8 @@ the link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[Git doc
|
||||
----
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
you are not author ...
|
||||
======================
|
||||
|
||||
Gerrit verifies for every pushed commit that the e-mail address of
|
||||
For every pushed commit Gerrit verifies 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
|
||||
@ -27,7 +27,7 @@ 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
|
||||
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.
|
||||
@ -92,7 +92,7 @@ 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
|
||||
you have to amend the commit, explicitly setting the author
|
||||
before continuing the rebase.
|
||||
|
||||
Here is an example that shows how the interactive rebase is used to
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
you are not committer ...
|
||||
=========================
|
||||
|
||||
Gerrit verifies for every pushed commit that the e-mail address of
|
||||
For every pushed commit Gerrit verifies 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
|
||||
@ -29,7 +29,7 @@ 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
|
||||
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.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Gerrit Code Review - i18n
|
||||
=========================
|
||||
|
||||
Aside from actually writing translations, there's some issues with
|
||||
Aside from actually writing translations, there are some issues with
|
||||
the way the code produces output. Most of the UI should support
|
||||
right-to-left (RTL) languages.
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ is configured and enabled within the DataSource.
|
||||
+
|
||||
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.
|
||||
directory so it's available to Gerrit Code Review.
|
||||
|
||||
|
||||
Jetty 7.x
|
||||
|
||||
@ -12,7 +12,7 @@ It is presumed you install it on a Unix based server such as any of the Linux
|
||||
flavors or BSD.
|
||||
|
||||
It's also presumed that you have access to an OpenID enabled email address.
|
||||
Examples of OpenID enable email providers are gmail, yahoo and hotmail.
|
||||
Examples of OpenID enable email providers are Gmail, Yahoo! Mail and Hotmail.
|
||||
It's also possible to register a custom email address with OpenID, but that is
|
||||
outside the scope of this quick installation guide. For testing purposes one of
|
||||
the above providers should be fine. Please note that network access to the
|
||||
@ -42,7 +42,7 @@ If Java isn't installed, get it:
|
||||
Create a user to host the Gerrit service
|
||||
----------------------------------------
|
||||
|
||||
We will run the service as a non privileged user on your system.
|
||||
We will run the service as a non-privileged user on your system.
|
||||
First create the user and then become the user:
|
||||
|
||||
----
|
||||
@ -50,7 +50,7 @@ First create the user and then become the user:
|
||||
$ sudo su gerrit2
|
||||
----
|
||||
|
||||
If you don't have root privileges you could skip this step and run gerrit
|
||||
If you don't have root privileges you could skip this step and run Gerrit
|
||||
as your own user as well.
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ as your own user as well.
|
||||
Download Gerrit
|
||||
---------------
|
||||
|
||||
It's time to download the archive that contains the gerrit web and ssh service.
|
||||
It's time to download the archive that contains the Gerrit web and ssh service.
|
||||
|
||||
You can choose from different versions to download from here:
|
||||
|
||||
@ -87,8 +87,8 @@ It's time to run the initialization, and with the batch switch enabled, we don't
|
||||
When the init is complete, you can review your settings in the
|
||||
file `'$site_path/etc/gerrit.config'`.
|
||||
|
||||
An important setting will be the canonicalWebUrl which will
|
||||
be needed later to access gerrit's web interface.
|
||||
An important setting is the canonicalWebUrl which will
|
||||
be needed later to access Gerrit's web interface.
|
||||
|
||||
----
|
||||
gerrit2@host:~$ cat ~/gerrit_testsite/etc/gerrit.config | grep canonical
|
||||
@ -216,7 +216,7 @@ Project creation
|
||||
Your base Gerrit server is now running and you have a user that's ready
|
||||
to interact with it. You now have two options, either you create a new
|
||||
test project to work with or you already have a git with history that
|
||||
you would like to import into gerrit and try out code review on.
|
||||
you would like to import into Gerrit and try out code review on.
|
||||
|
||||
New project from scratch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -231,14 +231,14 @@ This is done via the SSH port:
|
||||
user@host:~$
|
||||
----
|
||||
|
||||
This will create a repository that you could clone to work with.
|
||||
This will create a repository that you can clone to work with.
|
||||
|
||||
Already existing project
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The other alternative is if you already have a git project that you
|
||||
want to try out Gerrit on.
|
||||
First you have to create the project, this is done via the SSH port:
|
||||
First you have to create the project. This is done via the SSH port:
|
||||
|
||||
----
|
||||
user@host:~$ ssh -p 29418 user@localhost gerrit create-project --name demo-project
|
||||
@ -262,7 +262,7 @@ After that it's time to upload the previous history to the server:
|
||||
user@host:~/my-project$
|
||||
----
|
||||
|
||||
This will create a repository that you could clone to work with.
|
||||
This will create a repository that you can clone to work with.
|
||||
|
||||
|
||||
My first change
|
||||
@ -294,7 +294,7 @@ Then make a change to it and upload it as a reviewable change in Gerrit.
|
||||
|
||||
Usually when you push to a remote git, you push to the reference
|
||||
`'/refs/heads/branch'`, but when working with Gerrit you have to push to a
|
||||
virtual branch representing "code review before submittal to branch".
|
||||
virtual branch representing "code review before submission to branch".
|
||||
This virtual name space is known as /refs/for/<branch>
|
||||
|
||||
----
|
||||
@ -319,11 +319,11 @@ Quick Installation Complete
|
||||
---------------------------
|
||||
|
||||
This covers the scope of getting Gerrit started and your first change uploaded.
|
||||
It doesn't give any clue as to how the review workflow works, please find
|
||||
It doesn't give any clue as to how the review workflow works, please read
|
||||
link:http://source.android.com/submit-patches/workflow[Default Workflow] to
|
||||
learn more about the workflow of Gerrit.
|
||||
|
||||
To read more on the installation of Gerrit please read link:install.html[the detailed
|
||||
To read more on the installation of Gerrit please see link:install.html[the detailed
|
||||
installation page].
|
||||
|
||||
|
||||
|
||||
@ -199,7 +199,7 @@ Site Customization
|
||||
------------------
|
||||
|
||||
Gerrit Code Review supports some site-specific customization options.
|
||||
For more information, see the related topic in this manual:
|
||||
For more information, see the related topics in this manual:
|
||||
|
||||
* link:config-reverseproxy.html[Reverse Proxy]
|
||||
* link:config-sso.html[Single Sign-On Systems]
|
||||
|
||||
@ -27,7 +27,7 @@ applied to the code base. However Gerrit goes a step further making it
|
||||
simple for all committers on a project to ensure that changes are
|
||||
checked over before they're actually applied. Because of this Gerrit
|
||||
is equally useful where all users are trusted committers such as may
|
||||
the case with closed-source commercial development. Either way it's
|
||||
be the case with closed-source commercial development. Either way it's
|
||||
still desirable to have code reviewed to improve the quality and
|
||||
maintainability of the code. After all, if only one person has seen
|
||||
the code it may be a little difficult to maintain when that person
|
||||
@ -337,7 +337,7 @@ HEAD is now at d5dacdb... Change to a proper, yeast based pizza dough.
|
||||
Easy as that, we now have the change in our working copy to play with.
|
||||
You might be interested in what the numbers of the refspec mean.
|
||||
|
||||
* The first *68* is the id if the change +mod 100+. The only reason
|
||||
* The first *68* is the id of the change +mod 100+. The only reason
|
||||
for this initial number is to reduce the number of files in any given
|
||||
directory within the git repository.
|
||||
* The second *68* is the full id of the change. You'll notice this in
|
||||
@ -379,7 +379,7 @@ main screen. Just as Code Review and Verify are different operations
|
||||
that can be done by different users, Submission is a third operation
|
||||
that can be limited down to another group of users.
|
||||
|
||||
Activating the _Publish and Submit_ or _Submit Patch Set X_ button
|
||||
Clicking the _Publish and Submit_ or _Submit Patch Set X_ button
|
||||
will merge the change into the main part of the repository so that it
|
||||
becomes an accepted part of the project. After this anyone fetching
|
||||
the git repository will receive this change as a part of the master
|
||||
|
||||
@ -11,22 +11,22 @@ change
|
||||
------
|
||||
The Gerrit change being reviewed, or that was already reviewed.
|
||||
|
||||
project:: Project path in Gerrit
|
||||
project:: Project path in Gerrit.
|
||||
|
||||
branch:: Branch name within project
|
||||
branch:: Branch name within project.
|
||||
|
||||
topic:: Topic name specified by the uploader for this change series
|
||||
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)
|
||||
number:: Change number (deprecated).
|
||||
|
||||
subject:: Description of change
|
||||
subject:: Description of change.
|
||||
|
||||
owner:: Owner in <<account,account attribute>>
|
||||
owner:: Owner in <<account,account attribute>>.
|
||||
|
||||
url:: Canonical URL to reach this change
|
||||
url:: Canonical URL to reach this change.
|
||||
|
||||
commitMessage:: The full commit message for the change.
|
||||
|
||||
@ -118,7 +118,7 @@ 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
|
||||
project:: Project path in Gerrit.
|
||||
|
||||
refName:: Ref name within project.
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ DESCRIPTION
|
||||
-----------
|
||||
Scans every submitted change and creates an initial notes
|
||||
branch detailing the previous submission information for
|
||||
each merged changed.
|
||||
each merged change.
|
||||
|
||||
This task can take quite some time, but can run in the background
|
||||
concurrently to the server if the database is MySQL or PostgreSQL.
|
||||
|
||||
@ -19,7 +19,7 @@ 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
|
||||
If run in an existing `$site_path`, init will upgrade some resources
|
||||
as necessary.
|
||||
|
||||
OPTIONS
|
||||
|
||||
@ -32,7 +32,7 @@ by setting the `Accept` HTTP request header to include
|
||||
----
|
||||
|
||||
JSON responses are encoded using UTF-8 and use content type
|
||||
`application/json`. The JSON response body starts with magic prefix
|
||||
`application/json`. The JSON response body starts with a magic prefix
|
||||
line that must be stripped before feeding the rest of the response
|
||||
body to a JSON parser:
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ Gerrit Code Review - Change-Ids
|
||||
Description
|
||||
-----------
|
||||
|
||||
Gerrit Code Review sometimes relies upon Change-Id lines in the
|
||||
Gerrit Code Review sometimes relies upon a Change-Id line at 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
|
||||
@ -37,7 +37,7 @@ 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
|
||||
To avoid confusion with commit names, Change-Ids are typically prefixed with
|
||||
an uppercase `I`.
|
||||
|
||||
Creation
|
||||
@ -125,7 +125,7 @@ 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.
|
||||
pasting the lines into the search box at the top-right of the web interface.
|
||||
|
||||
If Gerrit already knows about more than one Change-Id, pick one
|
||||
to keep in the squashed commit message, and manually abandon the
|
||||
|
||||
@ -149,7 +149,7 @@ library] is used for evaluation of such patterns.
|
||||
[[tr,bug]]
|
||||
tr:'ID', bug:'ID'::
|
||||
+
|
||||
Search for changes whose commit message contains 'ID' and matched
|
||||
Search for changes whose commit message contains 'ID' and matches
|
||||
one or more of the
|
||||
link:config-gerrit.html#trackingid[trackingid sections]
|
||||
in the server's configuration file. This is typically used to
|
||||
@ -166,7 +166,7 @@ of the argument.
|
||||
[[message]]
|
||||
message:'MESSAGE'::
|
||||
+
|
||||
Changes that matches 'MESSAGE' arbitrary string in body commit messages.
|
||||
Changes that match 'MESSAGE' arbitrary string in the commit message body.
|
||||
|
||||
[[file]]
|
||||
file:^'REGEX'::
|
||||
@ -229,7 +229,7 @@ Same as `reviewer:self`.
|
||||
|
||||
is:open::
|
||||
+
|
||||
True if the change is other open or submitted, merge pending.
|
||||
True if the change is either open or submitted, merge pending.
|
||||
|
||||
is:draft::
|
||||
+
|
||||
@ -246,7 +246,7 @@ Same as <<status,status:'STATE'>>.
|
||||
[[status]]
|
||||
status:open::
|
||||
+
|
||||
True if the change state is other 'review in progress' or 'submitted,
|
||||
True if the change state is either 'review in progress' or 'submitted,
|
||||
merge pending'.
|
||||
|
||||
status:reviewed::
|
||||
@ -268,7 +268,7 @@ Change has been merged into the branch.
|
||||
|
||||
status:abandoned::
|
||||
+
|
||||
Change has been abandoned by the change owner, or administrator.
|
||||
Change has been abandoned by the change owner, or an administrator.
|
||||
|
||||
|
||||
Boolean Operators
|
||||
@ -304,7 +304,7 @@ that are returned, as more changes are considered.
|
||||
[[labels]]
|
||||
Labels
|
||||
------
|
||||
Label operators can be used to match approval score given during
|
||||
Label operators can be used to match approval scores 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.
|
||||
@ -323,7 +323,7 @@ A label name is any of the following:
|
||||
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.
|
||||
The easiest way to explain this is by example.
|
||||
|
||||
`label:CodeReview=2`::
|
||||
`label:CodeReview=+2`::
|
||||
@ -400,7 +400,7 @@ The special case `watchedby:self` applies to the caller.
|
||||
|
||||
draftby:'USER'::
|
||||
+
|
||||
Matches changes that 'USER' has left unpublished drafts on.
|
||||
Matches changes that 'USER' has left unpublished draft comments on.
|
||||
Since the drafts are unpublished, it is not possible to see the
|
||||
draft text, or even how many drafts there are. The special case
|
||||
of `draftby:self` will find changes where the caller has created
|
||||
|
||||
@ -18,7 +18,7 @@ to identify if it registers git submodules (if the commit registers
|
||||
any gitlinks and .gitmodules file with required info) and if so,
|
||||
a new submodule subscription is registered.
|
||||
|
||||
When a new commit of a registered submodule is merged, gerrit
|
||||
When a new commit of a registered submodule is merged, Gerrit
|
||||
automatically updates the subscribers to the submodule with a new
|
||||
commit having the updated gitlinks.
|
||||
|
||||
@ -31,7 +31,7 @@ is to provide a brief overview, further details can be found
|
||||
in the official git submodule command documentation.
|
||||
|
||||
Imagine a repository called 'super' and another one called 'a'.
|
||||
Also consider 'a' available in a running gerrit instance on "server".
|
||||
Also consider 'a' available in a running Gerrit instance on "server".
|
||||
With this feature, one could attach 'a' inside of 'super' repository
|
||||
at path 'a' by executing the following command when being inside
|
||||
'super':
|
||||
@ -86,12 +86,12 @@ has the same name as the destination branch of the commit having
|
||||
gitlinks/.gitmodules file.
|
||||
|
||||
The branch field of a submodule section is a custom git submodule
|
||||
feature for gerrit use. One should always be sure to fill it in
|
||||
feature for Gerrit use. One should always be sure to fill it in
|
||||
editing .gitmodules file after adding submodules to a super project,
|
||||
if it is the intention to make use of the gerrit feature introduced here.
|
||||
if it is the intention to make use of the Gerrit feature introduced here.
|
||||
|
||||
Any git submodules which are added and not have the branch field
|
||||
available in the .gitmodules file will not be subscribed by gerrit
|
||||
available in the .gitmodules file will not be subscribed by Gerrit
|
||||
to automatically update the superproject.
|
||||
|
||||
Detecting and Subscribing Submodules
|
||||
@ -114,7 +114,7 @@ is updated.
|
||||
|
||||
Imagine a superproject called 'super' having a branch called 'dev'
|
||||
having subscribed to a submodule 'a' on a branch 'dev-of-a'. When a commit
|
||||
is merged in branch 'dev-of-a' of 'a' project, gerrit automatically
|
||||
is merged in branch 'dev-of-a' of 'a' project, Gerrit automatically
|
||||
creates a new commit on branch 'dev' of 'super' updating the gitlink
|
||||
to point to the just merged commit.
|
||||
|
||||
@ -123,11 +123,11 @@ Canonical Web Url
|
||||
|
||||
Gerrit will automatically update only the superprojects that added
|
||||
the submodules of urls of the running server (the one described in
|
||||
the canonical web url value in gerrit configuration file).
|
||||
the canonical web url value in Gerrit configuration file).
|
||||
|
||||
The Gerrit instance administrator group should always certify to
|
||||
provide the canonical web url value in its configuration file. Users
|
||||
should certify to use the url value of the running gerrit instance to
|
||||
should certify to use the url value of the running Gerrit instance to
|
||||
add/subscribe submodules.
|
||||
|
||||
Removing Subscriptions
|
||||
|
||||
@ -46,7 +46,7 @@ and paste it into Gerrit's web interface:
|
||||
|
||||
[TIP]
|
||||
Users who frequently upload changes will also want to consider
|
||||
starting a `ssh-agent`, and adding their private key to the list
|
||||
starting an `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
|
||||
@ -57,7 +57,7 @@ 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
|
||||
to connect to Gerrit's SSHD port. By default Gerrit runs on
|
||||
port 29418, using the same hostname as the web server:
|
||||
|
||||
====
|
||||
@ -104,7 +104,7 @@ git push
|
||||
Create Changes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
To create new changes for review, simply push into the project's
|
||||
To create new changes for review, simply push to the project's
|
||||
magical `refs/for/'branch'` ref using any Git client tool:
|
||||
|
||||
====
|
||||
|
||||
Loading…
Reference in New Issue
Block a user