Rapid Moodle development using Git

Recently I've been doing a lot of Moodle development, and every time I start a feature, or work on a bug, I've been creating a new branch. I often also create a new database, and a fresh install just to make sure that there's nothing fruity going on. All this has meant that I've had branches and databases coming out of my ears.

Since I've just taken possession of a new desktop for work, I've taken the opportunity to start afresh with my Moodle branches and I'm trying to be more organised in my branch creation. To that end, I've got the following system going:

• Generic moodle bug: MDL-<bug number>-<revision>
• Version for master: MDL-<bug number>-master-<revision>
• Version for 2.0: MDL-<bug number>-MOODLE_20_STABLE-<revision>
• Version for 2.1: MDL-<bug number>-MOODLE_21_STABLE-<revision>

This allows me to start work on a bug, and have relevant revisions to my patches in a sane and reasonably sensible (if not a touch long) fashion.

To make life simpler still, I've added to my moodle/config.php. This selects my database (and optionally database username which is sometimes handy) based on my branch name.

<?php

$branch = exec("git branch --no-color | grep '^* '| sed 's/^* //'");
$dbuser = 'moodle';

// First check for generic branch parents
if (preg_match('/master/', $branch)) {
    $newbranch = 'master';
} else if (preg_match('/MOODLE_20_STABLE/', $branch)) {
    $newbranch = 'MOODLE_20_STABLE';
} else if (preg_match('/MOODLE_21_STABLE/', $branch)) {
    $newbranch = 'MOODLE_21_STABLE';
} else if (preg_match('/MDL-/', $branch)) {
    // Any remaining MDL- matches which don't specify a branch will be
    // assumed to be on master
    $newbranch = 'MOODLE_21_STABLE';
}

// And now more specific parents
switch ($branch) {
    case 'example':
        $dbuser = 'some-other-dbuser';
        $newbranch = 'master';
        break;
    default:
        break;
}

$branch = $newbranch;

...

$CFG->dbname = 'moodle-' . $branch;
$CFG->dbuser = $dbuser;

I guess I'll see how it goes, but so far it's working well and I intend to replicate this with Mahara too.

Mahara 1.4 Cookbook Review

A short while ago I was asked to review the Mahara 1.4 Cookbook, written by Ellen Murphie. I was quite excited to see what suggestions she had to offer on the many differing ways to use Mahara.

The book is split into eight chapters covering different types of user and use-cases with each chapter being made of a number of recipes (well, it is a cookbook!). There are suggestions utilising many of the features of Mahara, plus in depth steps on how to carry out each recipe. Although the book does assume that you've got a little prior knowledge on how to use Mahara, there are some very basic recipes for those who have not.

The first chapter, Mahara for the Visual Arts, focuses primarily on visual arts and makes some great suggestions, such as combining the Collections feature with Audacity to create an audio-guided tour which I particularly liked.  I was especially pleased to see discussion of Creative Commons licensing -- a subject which more authors and artists should be aware of!  The second chapter, Literature and Writing, gives some good ideas for using Pages to present journals in a variety of different ways. I liked the combination of RSS feeds and Journals within a Page to present a newspaper page (A Daily Gazette) complete with topical and up-to-date external content such as YouTube.  I was also pleased to see that the book covered ePortfolio for professional use and not just for students with the inclusion of chapter three, The Professional Portfolio. I liked the way that a combination of Secret URLs were suggested as a way to give different potential employers access to a personalised Curriculum Vitae. The suggestion of uploading HTML, and Copying Pages were very useful to avoid duplicating effort and I'm glad that they were included.

Chapters four and five focused more on using Mahara as a teaching tool than for users wanting to create portfolios and I was surprised to see them in the middle of the book rather than at the end.  Chapter four, Working with Groups, gives ideas on different ways of using groups - primarily for collaboration, but also for assessment. It gives an introduction to the possible uses of groups, and details some of the basic operations (adding and removing members), and also goes on to detail some ideas on how to use groups to engage students more.  Primary education and teaching is a topic I'm not overly familiar with and I was surprised by the number of recipes in chapter five, The Primary Education Portfolio. I was intrigued by many of the ideas - I'd previously assumed that primary school aged students wouldn't typically work heavily with Mahara.  I liked the recipe on creating a reading list with book reports.

I felt that chapter six, The Social Portfolio, gave lots of good ideas to help users to organise their profile page and include all sorts of external content (e.g. Twitter, and external blogs) and it was good to see mention of the RSS export features of Mahara.

Chapters seven and eight were more focused on higher education and the recipes focused on using features of Mahara to exhibit work and information for college applications. Several of the recipes suggested similar ideas but used the techniques in different ways. I liked that the topic of archiving portfolio content was covered, though disappointed that LEAP2A was not actually discussed.

Overall, I found the book very interesting and it gave me some thoughts on how others might be using Mahara. I was a little disappointed that some of the tips at the end of the book weren't included earlier (notably the ability to upload a zip file and unzip it in Mahara, rather than uploading each file individually -- this wasn't touched upon until chapter 7), but I don't think that this detracts from the book as a whole as they were still covered.

I think that this book would be ideally suited to users wanting to be able to make their work stand out and be seen, but also to teachers and advisors looking for ideas to give their students. I shall definitely be recommending this book to others.

The power of git - splitting a commit

Every blog has to have a customary first post - or at least, almost every blog seems to. Rather than mine just saying that I'm starting a new blog, and I'll try and keep it up to date and blah blah blah, I thought I'd actually post some content.

For the past 9 months or so, I've been fairly heavily involved in an open source project called Mahara. Mahara is an ePortfolio system and I'm sure that I'll post about it more in the near future so I won't go into lots of detail now. Needless to say though, the work I've been doing on it has involved a variety of customisations and any sane developer stores, manages and tracks their work using a version control system or VCS. The mahara project uses git.

Git is probably the most powerful version control system I've come across and enables you to manage your source and commits with minimal effort and confusion - it's probably the only VCS I've ever used which works for you rather than making you work around it. That said, some of the really powerful features of git take a bit of understanding.

Earlier today I was telling someone how you can use git in some really cool and interesting ways. One of the things I do frequently is to take a commit and split it into a series of logical commits and I thought that I'd share this.

Setting up a quick git repository
If you want to try and follow with my examples, I've pushed my sample repository to gitorious.org. You can skip the first part by cloning it with:

git clone git://gitorious.org/thamblings/git-split-commits.git

Say that you've created a quick git repository with a few files in it:

# Create a new git repository
cd /tmp
mkdir git-example
cd git-example/
git init

# Commit the first file
echo "First File" >> one 
git add one 
git commit -m "First file committed"

# Now add a few more commits/files
echo "Second File" >> two 
echo "Third File" >> three
git add .
git reset
git add two 
git commit -m "Second File"
git add three
git commit -m "Third File"

# Now add two files in the same commit
echo "Fourth File" >> four
echo "Fifth File" >> five
git add .
git commit -m "Fourth and Fifth Files"

# And another file
echo "Sixth File" >> six 
git add .
git commit -m "Sixth File"

# Let's see what we've done
git log

But we made a mistake...
But wait a second - files four and five should have been in different files. Let's split them out.

Let's rewrite history
First we'll check out a new branch, and then we'll do an interactive rebase to edit the commit:

git checkout -b fixcommits
git rebase -i HEAD~2

We should get something like:

pick 0d3abd7 Fourth and Fifth Files
pick feaeea8 Sixth File

We want to edit commit 0d3abd7, so change that to an edit - you can use 'e' instead:

edit 0d3abd7 Fourth and Fifth Files
pick feaeea8 Sixth File

That takes us to the point after the commit 'Fourth and Fifth Files' and before 'Sixth File'.
We can then use git reset the state of our current HEAD.

git reset HEAD~1

We can then re-add and re-commit each file:

git add four
git commit -m "Fourth File"
git add five
git commit -m "Fifth File"

We can then continue our rebase and we'll be left with our finished article:

git rebase --continue

Let's get things back to master
And if we're happy with what we have, we can check it back in to our master branch with another rebase

git checkout master
git rebase fixcommits

The same also works for other git additions. So you could add parts of a file with an interactive git add (git add -pi) for example.