Page History

...

...

$ git clone -b master git://git.whamcloudhpdd.intel.com/fs/lustre-release.git lustre-master
$ cd lustre-master

...

[user]
        name = Random J. Developer
        email = random@developer.example.org
[remote "review"]
        url = ssh://random@review.whamcloud.com:29418/fs/lustre-release 

Now all git commit commands in any repository will use this name/email regardless of which user account is used to do the modifications, if using $HOME/.gitconfig file. If you want to specify a different name or email for a specific repository, it is possible to add this information to the .git/config file in that specific repository. See commit comment details below.  The optional [remote "review"] block adds an alias for the remote Gerrit repository to simplify pulling updates and pushing patches, and should only be added in the local .git/config file.

For Lustre patches, the code needs to follow For Lustre patches, the code needs to follow specific Lustre Code Style Guidelines (which is basically the Linux kernel CodingStyle, with extra details for Lustre), as do the commit comments for each patch. In order to help maintain the uniform code style, Lustre-specific Git commit hooks should be installed in all Lustre development trees. In the top-level directory of the checked-out Lustre repository install the hooks using:

ln -sf ../../contrib/buildgit-hooks/commit-msg .git/hooks/
ln -sf ../../buildcontrib/git-hooks/prepare-commit-msg .git/hooks/

This will run the buildcontrib/git-hooks/prepare-commit-msg script from the currently-checked-out Lustre tree to run the modifications through the buildcontrib/scripts/checkpatch.pl script for style errors, and the buildcontrib/git-hooks/commit-msg script afterward to verify the format of the commit message itself.  The format of commit comments is described below.

...

git push ssh://USER@review.whamcloud.com:29418/fs/lustre-release HEAD:refs/for/b2_59

for the b2_59 branch of the fs/lustre-release repo, or:

...

For convenience, you can add this to your ~/.ssh/config file:

Host review
  Hostname review.whamcloud.com
  Port 29418
  User \{YourUserid\}
  IdentityFile ~/.ssh/my-key-id_rsa

...

In order to actually get a patch landed, you need to request at least two reviews in Gerrit for the patch. This is done by visiting the Gerrit web page for the change (at the URL returned when the commit was pushed, or it can be found from your home page after logging in). Enter the name or email address for the reviewer and click the Add Reviewer button.... button in the top right corner.

In conjunction with the two review requests, the patch has to successfully build on all supported architecture/distro combinations, and pass the automatic testing (as reported by Maloo). Once the patch has passed two reviews (+1 or +2 Review from reviewers that are not the original developer), built correctly (+1 Verified from Hudson/ Jenkins), and has passed autotest (+1 Verified from Maloo) the patch can be submitted for landing by adding Gerrit Gatekeeper using the Add Reviewerwill automatically appear in the Gerrit Gatekeeper's list of patches to land.

It is the responsibility of the patch submitter to  to request the reviewers to look at the patch or to request patch landing, if this is not happening in a timely manner, by adding a comment into the patch.

...

In the case where changes need to be based on a patch from another developer, it is possible to check out the desired patch from Gerrit using one of the supplied Git URLs in the Download section under the patchset. Select the checkout and Anonymous HTTP tags or SSH options, then copy the URL and paste it into a working Lustre checkout, for at the command prompt of a previously checked-out Lustre tree.  For example to fetch patchset 16 from http://review.whamcloud.com/1264, create a branch for it, and then create a new branch for your local changes based on that change, use:

[lustre]$ git fetch http://review.whamcloud.com/p/fs/lustre-release refs/changes/64/1264/16 && git checkout FETCH_HEAD
[lustre]$ git checkout -b b_1264
[lustre]$ git checkout -b b_1264_my_changes
{edit local tree to make changes as usual}
[lustre]$ git commit -a

Any changes in the b_1264_my_changes will be based on top of those of b_1264. When b_1264_my_changes is pushed to Gerrit, it will have a dependency on change 1264, so it will not be able to land until change 1264 itself is landed.  It is typically not desirable rebase the b_1264 branch or your local branch to a new version of master or modify it, or it will cause the other developer's patch to be updated in Gerrit, and lose its existing review and test results.  However, in some cases this is desirable, and Gerrit allows a user other than the original author to push an updated version of the patch (using the same Change-Id: label) in case there is a problem with the original patch (e.g. no longer applies, has a bug, etc).

If you already have the changes in a local branch (e.g. b_my_changes) and want to rebase that branch on top of another uncommitted patch from Gerrit, the process is similar:

...

Switch to the branch you want to create a branch in (normally master or b2_59).

Create the tag with:

git tag -a TAG_NAME

...