Bugzilla:Committing Patches: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:


Make sure you've identified yourself via [http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup git config].
Make sure you've identified yourself via [http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup git config].
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com


Before pushing, make sure your commit message is of the form
Before pushing, make sure your commit message is of the form

Revision as of 14:35, 11 March 2014

As of 2014/03/11, the repositories of record for Bugzilla are on git.mozilla.org. Bugzilla follows a centralized work flow; all commits must be pushed to git.mozilla.org. Some Bugzilla repositories are also mirrored, read-only, to bzr.mozilla.org and, eventually, github.com.

These instructions are specific to the core Bugzilla repository but also apply, suitably modified, to qa and other Bugzilla-related repos.

To gain commit rights, you'll need to become a Mozilla Committer. For Bugzilla, the requirement is that one of the Assistant Project Leads or the Project Lead vouch for you. Your bug should be filed in the Repository Account Requests component. (Note: If you are already a Mozilla Committer and you just need Bzr access, just file a bug in this component requesting it and CC one of the Bugzilla leads.)

Make sure you've identified yourself via git config.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Before pushing, make sure your commit message is of the form

Bug <id>: <description>
r=<reviewer>, a=<approver>

Replace <id> and <description> appropriately. r= indicates the person(s) who reviewed your patch. a= indicates the person who approved it for check-in.

Note that the description given on the commit comment should describe what the patch actually does (in a broad sense), which may not necessarily match the summary of the bug being fixed. For example, of the summary of the bug is "Bugzilla doesn't do Foo", then your description in the commit comment should say something like "Make Bugzilla do Foo".

Once you've committed or merged to the right branch (usually master) of your local clone, you are ready to push it to git.mozilla.org. Write access is via ssh. Assuming you have already cloned it via the read-only https protocol, you can either add a new remote or update an existing remote:

git remote add <new remote name> ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
# or if you originally cloned from https
git remote set-url origin ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git

If you ever need to set up a new local repo, you can just clone it directly:

git clone ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git

Then push to git.mozilla.org:

git push <remote name> <branch name>

<remote name> will be origin if you cloned directly from ssh or used set-url; otherwise it will be the name you gave to git remote add. <branch name> will usually be master, unless you are applying a security or other crucial fix to an older branch.

After the push successfully completes, paste the output into the bug as a new comment and resolve it FIXED.