Actions

Difference between revisions of "Developer Area/Getting Code from Git"

From Mahara Wiki

< Developer Area
Line 9: Line 9:
 
   git checkout -b 1.2_STABLE origin/1.2_STABLE
 
   git checkout -b 1.2_STABLE origin/1.2_STABLE
  
<br /> Once you've got the code from git, you should point your webserver at the htdocs directory if you want to run it.  You can update the code by running the "git pull" command from anywhere inside your checkout.
+
Once you've got the code from git, you should point your webserver at the htdocs directory if you want to run it.  You can update the code by running the "git pull" command from anywhere inside your checkout.
 +
 
 +
===Setting up Gerrit in your local Mahara repository===
 +
 
 +
First of all you need to add a new gerrit remote to your repo (substitute username with the one you have chosen at the step above):
 +
 
 +
git remote add gerrit ssh://'''username'''@reviews.mahara.org:29418/mahara
 +
 
 +
Apparently, '''the username is case-sensitive''', which is why we recommend using a lowercase one.
 +
 
 +
Also you will need to add a commit message hook to your repo, this will generate <tt>Change-Id:</tt> tags in commit messages which is required for proper gerrit functioning:
 +
 
 +
scp -p -P 29418 '''username'''@reviews.mahara.org:hooks/commit-msg .git/hooks/
 +
 
 +
===Submitting commits for review===
 +
 
 +
In order to push your changes for review, just push into the project's magical <tt>refs/for/'''remote_branchname'''</tt> ref. If you are pushing to the remote master branch and your current local branch is bug123456, your command will be:
 +
 
 +
git push gerrit HEAD:refs/for/'''master'''
 +
 
 +
Once you pushed, your change will be available for review on the [https://reviews.mahara.org/ Mahara code review system]. The single change will be created on review system for each commit you pushed. If you push several commits, gerrit will add dependencies between changes based on the git parent ref.
 +
 
 +
You may also push a single commit, simply use its hash:
 +
 
 +
git push gerrit '''38f4f96df''':refs/for/master
 +
 
 +
If you like, you may specify the topic tag that will be shown in your change details on review system. This tag may be associated with a group of changes if you use it for several commits. To do that, simply append it to the destination ref, e.g.
 +
 
 +
git push gerrit HEAD:refs/for/master/'''topic_for_this_change'''
 +
 
 +
===Making changes in existing commits===
 +
 
 +
The <tt>--amend</tt> flag on <tt>git commit</tt> will allow you to attach changes to a previous commit. This also works with the <tt>-s</tt> flag, if you forgot to sign-off originally.
 +
 
 +
Another option is commit squashing, below.
 +
 
 +
When your commit has been reviewed, you may require to make some changes before it will be accepted. The changes you will be doing should be [http://book.git-scm.com/4_interactive_rebasing.html squashed] into the same commit you originally pushed for review. You must ensure that the <tt>Change-Id:</tt>  line is preserved the same as in the original commit. This will make Gerrit matching this commit to the original one and appending your changes as a new patchset. The simplest workflow would be:
 +
# Make the required changes
 +
# Commit the changes
 +
#* The commit message does not matter as it will be removed when the commit is squashed, so random text here is fine.
 +
# Use [http://book.git-scm.com/4_interactive_rebasing.html interactive rebasing] to squash the latest commit into the previous commit.
 +
#* An example command for this would be: <tt>git rebase -i HEAD~2</tt>
 +
#* Find the latest commit in the list (it should be the bottom-most commit) and replace the short hash with 'f'. This is short for 'fixup', which will squash the commit into the one before it, and discard the commit message. (This is what we want.)
 +
Now you may push the amended commit to review system:
 +
 
 +
git push gerrit HEAD:refs/for/master
 +
 
 +
In Gerrit interface it will appear under the same change as a separate patchset ready for another review.
 +
 
 +
===Useful links===
 +
 
 +
* [https://reviews.mahara.org/Documentation/index.html Gerrit official documentation] 
 +
* [http://www.itk.org/Wiki/ITK/Gerrit/ReviewPrimer Gerrit Review Primer] - useful for getting familiar with review interface.
 +
 
 +
[[Category:Developer Area]]

Revision as of 20:08, 24 May 2011

Rather than using a standard release build of Mahara, you can check out the code from our git repository.

git clone git://gitorious.org/mahara/mahara.git    

If you check the project out from git, you have the option of checking out a specific feature branch of Mahara, if you're interested in one in particular. See http://gitorious.org/mahara/mahara for a list of all branches in our git repository. Example:

git clone git://gitorious.org/mahara/mahara.git
 cd mahara/
 git checkout -b 1.2_STABLE origin/1.2_STABLE

Once you've got the code from git, you should point your webserver at the htdocs directory if you want to run it.  You can update the code by running the "git pull" command from anywhere inside your checkout.

Setting up Gerrit in your local Mahara repository

First of all you need to add a new gerrit remote to your repo (substitute username with the one you have chosen at the step above):

git remote add gerrit ssh://username@reviews.mahara.org:29418/mahara

Apparently, the username is case-sensitive, which is why we recommend using a lowercase one.

Also you will need to add a commit message hook to your repo, this will generate Change-Id: tags in commit messages which is required for proper gerrit functioning:

scp -p -P 29418 username@reviews.mahara.org:hooks/commit-msg .git/hooks/

Submitting commits for review

In order to push your changes for review, just push into the project's magical refs/for/remote_branchname ref. If you are pushing to the remote master branch and your current local branch is bug123456, your command will be:

git push gerrit HEAD:refs/for/master

Once you pushed, your change will be available for review on the Mahara code review system. The single change will be created on review system for each commit you pushed. If you push several commits, gerrit will add dependencies between changes based on the git parent ref.

You may also push a single commit, simply use its hash:

git push gerrit 38f4f96df:refs/for/master

If you like, you may specify the topic tag that will be shown in your change details on review system. This tag may be associated with a group of changes if you use it for several commits. To do that, simply append it to the destination ref, e.g.

git push gerrit HEAD:refs/for/master/topic_for_this_change

Making changes in existing commits

The --amend flag on git commit will allow you to attach changes to a previous commit. This also works with the -s flag, if you forgot to sign-off originally.

Another option is commit squashing, below.

When your commit has been reviewed, you may require to make some changes before it will be accepted. The changes you will be doing should be squashed into the same commit you originally pushed for review. You must ensure that the Change-Id:  line is preserved the same as in the original commit. This will make Gerrit matching this commit to the original one and appending your changes as a new patchset. The simplest workflow would be:

  1. Make the required changes
  2. Commit the changes
    • The commit message does not matter as it will be removed when the commit is squashed, so random text here is fine.
  3. Use interactive rebasing to squash the latest commit into the previous commit.
    • An example command for this would be: git rebase -i HEAD~2
    • Find the latest commit in the list (it should be the bottom-most commit) and replace the short hash with 'f'. This is short for 'fixup', which will squash the commit into the one before it, and discard the commit message. (This is what we want.)

Now you may push the amended commit to review system:

git push gerrit HEAD:refs/for/master

In Gerrit interface it will appear under the same change as a separate patchset ready for another review.

Useful links