1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
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, `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.
+
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.
When Gerrit tries to do a merge, by default the merge will only
succeed if there is no path conflict. By selecting the checkbox
`Automatically resolve conflicts` Gerrit will try do a content merge
if 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 `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]
|
