GIT

Configuring GIT

Use the following commands to set your global git options in ~/.gitconfig:

git config --global user.name "John Doe"
git config --global user.email "john.doe@example.com"
git config --global sendemail.smtpserver "smtp.example.com"
git config --global push.default simple

You should replace "John Doe", "john.doe@example.com" and "smtp.example.com" in the commands above with appropriate values for you.

Creating a personal GIT repository at SourceForge

You also need to create a personal GIT repository at SourceForge, where the code will be published by the review script (it will also be sent out to the mailing list):

Go to the following URL (replace john-doe with your actual SourceForge User-ID): https://sourceforge.net/u/john-doe/activity/ in your web browser

Press "Add New..." at the far right on the toolbar. Select "GIT", give the new repository the label "Review" and the URL path "review". Press "Save".

Sending code for review

Set the following two environment variables (replace john-doe and 4711 with your SourceForge User-ID and the ticket number you are working on). The $OSAF_SOURCEFORGE_USER_ID variable is needed by the submit-review.sh script that you will run to send out the patches for review. The $ticket variable is not needed by the script; it is only needed by the commands on this wiki page.

export OSAF_SOURCEFORGE_USER_ID=john-doe
export ticket=4711

In the rare case that your SourceForge profile page uses a different user-id than the one you use to log in to SourceForge, you may also have to set OSAF_SOURCEFORGE_GIT_REPO_ID to the user ID for your profile page. You can find out if this is needed by navigatingh your web browser to your profile page at SourceForge (e.g. https://sourceforge.net/u/john-doe/profile) and examining the URL of the page. If the user-id part of the URL (john-doe) doesn't change, then you don't have to do anything special. If the user-id part changes from john-doe to something like userid-1234567 then you need to set OSAF_SOURCEFORGE_GIT_REPO_ID to userid-1234567.

Use the following commands to work on the ticket:

git clone -b develop ssh://${OSAF_SOURCEFORGE_USER_ID}@git.code.sf.net/p/opensaf/code opensaf-code
git checkout -b ticket-$ticket
#Work on the ticket and stage the changes
git commit
#Optionally work on a second patch for the same ticket
git commit
cd tools/devel/review
#Note: the following script will push the ticket branch to your personal
#repository that you created earlier, and also send the patches to the OpenSAF
#devel list.
./submit-review.sh

When the review has been ACKed, you push the code as follows:

git checkout develop
git pull
git checkout ticket-$ticket
git rebase --ignore-date develop
git checkout develop
git merge --ff-only ticket-$ticket
git push origin develop

You should normally only push to the develop branch in the official OpenSAF GIT repository. Important bug-fixes can sometimes also be needed on the release branch. Remember that the purpose of the release branch is to stabilize the code before the release, so if your bug-fix is unimportant and/or risky then please push it to the develop branch only, so that we minimize the risk of introducing new bugs on the release branch. We release OpenSAF once every one or two months, so if you push code to the relase branch then it will receive very little testing before it goes into a release. If you push it only to the develop branch then it will recevie at least one month of testing before going into a release.

• Example of an important bug-fix: a regression from the previous release. I.e. something that used to work in the previous release but now has become broken due to some recent change.
• Example of an unimportant bug-fix: a several-years-old defect ticket that no-one has cared to fix until you finally decided to do it. This fix is probably not very urgent and it might be better to put it only on the develop branch so that the fix receives more testing before it goes into a release.

When you have pushed an important bug-fix to the develop branch and you think it is important and risk-free enough to be pushed to the release branch, you can cherry-pick it to the release branch using the following commands (replace <revision> in the commands below with the actual revision (hexadecimal hash number) of the commit you wish to cherry-pick):

git checkout release
git pull
git cherry-pick --ff <revision>
git push origin release

Reviewing code in your local repository

When reviewing code, you can easily fetch the changes from the author's personal repository into a separate branch in your own local GIT repository. Use the following commands (replace 4711 and john-doe with the acutal ticket number and the author's SourceForge user name):

git fetch git://git.code.sf.net/u/john-doe/review ticket-4711
git checkout FETCH_HEAD
#Optionally run the following command to create a branch in your local
#repository:
git checkout -b ticket-4711