Page History

...

This creates a new branch based on master called my-brilliant-idea, and also makes it the current branch.

In order ensure that the commit description contains the correct name and email address for you, it is possible to specify this directly to Git creating or modifying the .gitconfig file in your home directory.

[user]
        name = Random J. Developer
        email = random@developer.example.org

Now all git commits will use this name/email regardless of which repository the changes are being made in.  If you want to specify a different name or email for a specific repository, it is possible to add the same information to the .git/config file in that specific repository.

Once you've made the change, and you're ready to create an inspection, you commit. Before you commit in git, you need to identify which files you want to commit using the "git add" command. If you haven't added any new files, and you want to commit all the files that you have changed (which is the usual case), then you can use the "-a" option to commit:

...

It is best to commit relatively frequently to keep your changes limited to a single fix. If you notice other, unrelated, issues that need to be fixed, then it's best to put them in a different commit, and usually on a different branch so they can be submitted to Gerrit separately for inspection, testing, and landing. The stash command is handy for this:

# While fixing a bug you notice something evil that must be fixed.
# First set your current work aside:
$ git stash

# Next go create a new branch and purge the ugliness you just discovered:
$ git create -b my-eyes-are-bleeding master
$ git commit -av

# Now go back to what you were working on:
$ git checkout my-brilliant-idea
$ git stash pop

In order ensure that the commit description contains the correct name and email address for you, it is possible to specify this directly to Git creating or modifying the .gitconfig file in your home directory.

[user]
        name = Random J. Developer
        email = random@developer.example.org

Now all git commits will use this name/email regardless of which repository the changes are being made in.  If you want to specify a different name or email for a specific repository, it is possible to add the same information to the .git/config file in that specific repository.

Formatting Git Commit Comments

See Submitting Changes 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.

...

Gerrit makes it easy to update an inspection request with a new patch, and doing this allows inspectors to see differences between the patches so they only need to inspect the changes. Also, the original inline comments are maintained and moved to the new patches. The key to updating keeping updated inspection requests linked to the original patch is the Change-Id field - this is what Gerrit uses to find the original patch to update.

And key critical thing to point out is you need update a new version of the full 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 the key step is to , 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 new patch onto 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 put 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 itthey's re combined into a single commit. If you don't have a Change-Id: line in your commit . Once that is donemessage (because you didn't install the commit-msg hook above) you can copy it from the change in Gerrit 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.

...