User:Mainframe98/Gerrit

A Gerrit/Git how-to for those moments our brains fail us with the lovely error message.
 * See also: Gerrit/Tutorial.

Creating a patchset

 * 1) Ensure the repository is set up with git review -s (remember: s for setup). Only required if there's not a .gitreview file in the repository
 * 2) Prepare the repository:
 * 3) Pull the latest changes from the repository with git pull origin master
 * 4) Create a branch for your changes with git checkout -b BRANCHNAME-GOES-HERE origin/master . Remember to name it appropriately, such as T2001/SHORT-DESCRIPTION
 * 5) Make your changes
 * 6) Prepare to commit:
 * 7) Check if the commit meets the Pre-commit checklist
 * 8) Write the commit message, for the guidelines see Gerrit/Commit message guidelines
 * 9) Commit with git commit . Don't use the -m flag because it restricts you to only the commit summary
 * 10) Prepare for pushing:
 * 11) Update your local repository with git pull --rebase origin master . It isn't strictly mandatory, but on repositories with a high update rate, it can prevent trouble
 * 12) Push your changes with git review -R . If you did not use the step above, omit -R as it tells git-review not to perform a rebase
 * 13) (Optional, but recommended) Add some reviewers. See Developers/Maintainers
 * 14) After the patch is merged or abandoned, switch back to master with git checkout master and remove the branch with git branch -d BRANCHNAME-GOES-HERE

Existing

 * Your current branch is not the one from the patchset but does exist locally


 * 1) Run git checkout and follow the steps below:
 * Your current branch is the one of the patchset.


 * 1) Make your changes (see above)
 * 2) Commit with git commit --amend
 * 3) * Use --all only when you want all changes, regardless if they have been staged, to be amended.
 * 4) Run git review -R to push the changes to Gerrit

Other

 * You don't have the patch yet.


 * 1) Get the patch with git review -d GERRIT-CHANGE-NUMBER-GOES-HERE . Beware that this does destroy your local changes, so stash or/and commit first.
 * 2) Follow the steps above.

Rebasing
You can do this two ways: Either by using Gerrit's rebase option (only available to patch owners or those with +2) or manually.

Manually
Using the rebase functionality of Gerrit does not always work. For those cases, follow the steps below:
 * 1) Pull the latest changes from the repository with git pull --rebase origin master
 * 2) Run git commit --amend . DON'T use the --all flag if you have uncommited changes!
 * 3) Run git review -R to push the rebase to Gerrit

Resolving conflicts
Sometimes patches have collected enough digi-dust that attempting to rebase them causes a merge conflict. In that case, using Gerrit's rebase option will not work. Instead, manually rebase, like mentioned above, but do the steps mentioned below after performing step 1. If any conflicts turn up after this, restart at step 1.
 * 1) Open the file(s) with the conflict(s) in an editor and resolve these. The lines above the dashes are the current state of the repository, below the dashes are the content of the patch. Pick the correct lines (or combine them).
 * 2) Mark the conflict resolved using git add.
 * 3) * Use git rm for removing files.
 * 4) Continue the rebasing with git rebase --continue

Creating a new branch
So far, I only know of one way to do this, using Gerrit's web interface:
 * 1) Find your project's Gerrit page and append ,branches : https://gerrit.wikimedia.org/r/#/admin/projects/PROJECTNAME/SUBPROJECTNAME,branches
 * 2) Create a new branch by specifying its name and the initial revision

Moving a commit to a new branch from master
Use case: You accidentally committed against origin/master, but wanted to commit to a specific branch.
 * 1) Run git fetch origin to ensure origin/master is up to date with Gerrit
 * 2) Run git rebase origin/master to move the commit to the tip of the master branch
 * 3) Create the branch with the requested name by running git branch BRANCH-NAME-GOES-HERE
 * 4) Run git status to check you are still on the master branch, if not, switch back with git checkout origin master
 * 5) Finally run git reset --hard origin/master to reset the master branch back to the original state before you committed

Setting the master branch to a specific commit
Obviously, you lose any unstashed/uncommitted changes with the commands below.
 * 1) Run git reset --hard COMMIT-HASH-GOES-HERE

UI
See https://review.gerrithub.io/Documentation/user-review-ui.html for an extensive guide that covers each part of the review interface.