61698b14e0
We previous use the section title style like: Section level 1 =============== Section level 2 --------------- Which have a problem in Asciidoctor that the number of "="s or "-"s must match the number of characters in the header exactly, as a result it's easy to make mistakes while changing the titles. Asciidoctor provides a better style like: = Section level 1 == Section level 2 So we switched to this style. Also fixed a bug in replace_macros.py, which will not cause any problem in the old style. Change-Id: I811dd7238735d98f662767c17086152cd69aea02
133 lines
4.1 KiB
Plaintext
133 lines
4.1 KiB
Plaintext
= Gerrit Code Review - Project Configuration
|
|
|
|
== 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 created.
|
|
|
|
=== 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
|
|
|
|
Either restart the server, or flush the `project_list` cache:
|
|
|
|
====
|
|
ssh -p 29418 localhost gerrit flush-caches --cache project_list
|
|
====
|
|
|
|
[[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, `Projects` >
|
|
`List` > my/project. 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.
|
|
+
|
|
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.
|
|
|
|
[[rebase_if_necessary]]
|
|
* Rebase If Necessary
|
|
+
|
|
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 the change is automatically rebased and then the branch is
|
|
fast-forwarded to the change.
|
|
|
|
When Gerrit tries to do a merge, by default the merge will only
|
|
succeed if there is no path conflict. A path conflict occurs when
|
|
the same file has also been changed on the other side of the merge.
|
|
|
|
If `Automatically resolve conflicts` is enabled, Gerrit will try
|
|
to do a content merge when a path conflict occurs.
|
|
|
|
|
|
== Registering Additional Branches
|
|
|
|
Branches can be created over the SSH port by any `git push` client,
|
|
if the user has been granted the `Create Reference` 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 `Projects` >
|
|
`List` > my/project > `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]
|
|
|
|
SEARCHBOX
|
|
---------
|