Page History

...

Formatting Git Commit Comments

Having good commit comments helps everyone that is working on the code. See Commit Comments for a detailed description of the commit comment style. If your comments are do not include the Change-Id: line as described below, the patch will be rejected at submission time.

...

Adding the Change-Id field

Gerrit will automatically identify updates to existing patches and update the existing request instead of creating a new one. This preserves the history of patch comments, and allows comparing old and new versions of a patch for more efficient inspections. For this to work properly the changes you create locally need to have a unique commit id in them. To get requires all changes to have the Commit-Id: field inserted automatically, copy the commit-msg hook from the build/ subdirectory into each Git repository's , or it will be rejected. It should be added automatically by the .git/hooks/ directory. This will update the commit message for changes you commit to your repository before they are submitted to Gerrit. The commit-msg hook will also verify that the commit message format matches the format specified above. Similarly, copying the prepare-commit-msg script from build/ to .git/hooks/ will run the build/checkpatch.pl script against each patch at commit time to check it against the Lustre Coding Guidelines.For older Lustre versions that are missing the commit hooks, they can be copied from a newer branch of Lustre (e.g. master), and the .git/hooks/ directory is shared among all branches (it is not updated when checking out a new branch)commit-comment script. See Commit Comments for a detailed description of the Commit-Id: field.

Creating Inspection Requests

...

A critical thing to point out is that you need submit a new version of the entire change - not just an update to the change. The usual way of doing this is to apply the updates to your tree as usual and create a new commit (this time the commit message doesn't matter as you are about to change it). Then, merge the two changes using git rebase -i <parent-branch>. Interactive rebase will display a list of patches in an editor, and you can "squash" the the modifications to the patch in the new commit into the original patch. (See the help text in the commit message editor window for more information.) Then it will put you in an editor again to manually merge the two commit messages. Make sure you keep the original Change-Id: line, and delete the new one, and edit the commit messages so they're combined into a single commit. If you don't have a Change-Id: line in your commit message (because you didn't install the commit-msg hook above, do that now, see Commit Comments) you can copy it from the top Gerrit web page for that change and paste it into the new commit message. Once the change is committed, push your branch to Gerrit again, and the original request will be updated with the new version of the patch.

...