Adds new section to cover the create reference permission that's new in Gerrit 2.2.x. Some examples of when to use this permission included. Change-Id: Iad959607394f13aea2b0e1a34e4eda9e22223f9b Signed-off-by: Fredrik Luthander <fredrik.luthander@sonyericsson.com>
		
			
				
	
	
		
			127 lines
		
	
	
		
			3.9 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			127 lines
		
	
	
		
			3.9 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, `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]
 |