Confirm
1,927
edits
Changes
Created page with "The Bugzilla Project uses the [http://http://git-scm.com/ git] Version-Control System. You can see the contents of the Bugzilla git repository at [http://git.mozilla.org/bugzi..."
The Bugzilla Project uses the [http://http://git-scm.com/ git] Version-Control System. You can see the contents of the Bugzilla git repository at [http://git.mozilla.org/bugzilla/bugzilla/].
= Checking Code Out of git =
The simplest way to get the latest Bugzilla development code is:
git clone http://git.mozilla.org/bugzilla/bugzilla
That will clone the Bugzilla git repository into a directory called "bugzilla" and will checkout the "master" branch.
If you want other branches, in the bugzilla directory simply checkout another branch:
cd bugzilla
git checkout 4.2
That will switch the files in the working directory to latest commit to the 4.2 branch.
== Getting A Specific Release ==
Every time we release a version of Bugzilla, we tag the git repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:
git checkout bugzilla-4.1.3
That will switch the files in the working directory to the commit released as version 4.1.3.
You will usually get a warning here about being in a "detached HEAD" state; this is fine unless you'll be modifying the code in your installation, at which point you should create a local branch to preserve your change history.
To see a list of all the tags available do
git tag
= Updating to a Newer Release =
== No local changes ==
If you have no local changes to any tracked files, upgrading to both minor and major releases is simple:
git fetch
git checkout bugzilla-(version)
where ''(version)'' is the version number that you want to update to, like <code>4.4.2</code>.
== Local, uncommitted changes ==
The above checkout command will fail if you've made any modifications to files you checked out from git with a warning about overwriting local changes. In this case, the simple solution is to stash and then reapply your changes (assuming you've done the "git fetch" already):
git stash save
git checkout bugzilla-(version)
git stash apply
However, it is better to create a local branch, which is one of git's strengths. You can track your customizations and merge in changes from upstream.
== Local branch ==
...
= Creating patches with git =
= Checking in using git =
See [[Bugzilla:Committing_Patches]].
= Writing Patches On Top of Other Patches =
= Checking Code Out of git =
The simplest way to get the latest Bugzilla development code is:
git clone http://git.mozilla.org/bugzilla/bugzilla
That will clone the Bugzilla git repository into a directory called "bugzilla" and will checkout the "master" branch.
If you want other branches, in the bugzilla directory simply checkout another branch:
cd bugzilla
git checkout 4.2
That will switch the files in the working directory to latest commit to the 4.2 branch.
== Getting A Specific Release ==
Every time we release a version of Bugzilla, we tag the git repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:
git checkout bugzilla-4.1.3
That will switch the files in the working directory to the commit released as version 4.1.3.
You will usually get a warning here about being in a "detached HEAD" state; this is fine unless you'll be modifying the code in your installation, at which point you should create a local branch to preserve your change history.
To see a list of all the tags available do
git tag
= Updating to a Newer Release =
== No local changes ==
If you have no local changes to any tracked files, upgrading to both minor and major releases is simple:
git fetch
git checkout bugzilla-(version)
where ''(version)'' is the version number that you want to update to, like <code>4.4.2</code>.
== Local, uncommitted changes ==
The above checkout command will fail if you've made any modifications to files you checked out from git with a warning about overwriting local changes. In this case, the simple solution is to stash and then reapply your changes (assuming you've done the "git fetch" already):
git stash save
git checkout bugzilla-(version)
git stash apply
However, it is better to create a local branch, which is one of git's strengths. You can track your customizations and merge in changes from upstream.
== Local branch ==
...
= Creating patches with git =
= Checking in using git =
See [[Bugzilla:Committing_Patches]].
= Writing Patches On Top of Other Patches =
