| 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 |
| --------- |