Hi Shaun,
In my two previous jobs, I've handled running Moodle based on a git repository, so I have some experience of this.
We went for a fairly comprehensive approach which I've blogged on. I understand that the Open University in the UK follow a similar kind of pattern, though I'm not aware of exactly how they do things from a technical standpoint. Since I wrote my blog post (and joined Moodle HQ), David Mudrak has moved most of the sites at Moodle HQ to using this same method.
The relevant blog post is at http://thamblings.blogspot.com.au/2013/07/upgrading-moodle-from-git.html - apologies, it's a fairly technical post. I should note that much of the original work in this was conceived by Dan Poltawski and others, and that I've made some refinements to it for sensibility. As I say, since that blog post, Moodle HQ has moved down the same route, and I've spoken to another UK-based University who have based their strategy on the same concept.
Onto your specific problem, I'm afraid that what you've been doing to date has been wrong and this is why you get a detached head. It sounds as though what you've been doing is:
mkdir moodle
cd moodle
git init
git checkout -b v2.5.0
unzip ~/path/to/moodle_2.5.0.zip
git add .
git commit -m 'v2.5.0'
// Wait some time until the next release.
git checkout -b v2.5.1
unzip ~/path/to/mooodle_2.5.1.zip
git add .
git commit -m 'v2.5.1'
// Wait some time until the next release.
git checkout -b v2.6.0
unzip ~/path/to/mooodle_2.6.0.zip
git add .
git commit -m 'v2.6.0'
This has different pre to what we push in Moodle, so when you've added our remote, this is why you get a detached head - the pre is not correctly related to the Moodle prebase and has a different history. What you should try is:
git clone https://github.com/moodle/moodle.git
cd moodle
# Create a new empty repository on github.
git remote add public git@github.com:andrewnicols/mydeploymentrepository.git
# Checkout a new branch for your school based on the v2.5.0 release tag.
git checkout -b myschool_25 v2.5.0
# Add your own changes here.
cp ~/path/to/plugin mod/plugin
git add mod/plugin
git commit -m 'mod_plugin: Add version 201402700'
# Rinse, Wash, Repeat.
cp ~/path/to/plugin block/plugin
git add block/plugin
git commit -m 'block_plugin: Add version 201402700'
# Tag your release - this is best practice and highly recommended.
# Use a concatanation of the actual Moodle version (e.g. v2.5.0, and your sub-version so that you can include new features on v2.5.0
git tag 'myschool_v2.5.0-0'
# Push everything to your public github:
git push public myschool_25
git push public --tags
# Wait some time until the next release.
# Fetch the latest commits from upstream:
git fetch origin
# Merge in the latest branch:
git merge v2.5.1
# Re-tag and push:
git tag 'myschool_v2.5.1-0'
git push public myschool_25
git push public --tags
###
# Oh noes - we need some random bugfix from v2.5.2 which hasn't been released yet:
# Fetch the Moodle repo
git fetch origin
# Cherry-pick the commit(s):
git cherry-pick
git cherry-pick
git cherry-pick
# Re-tag and push:
git tag 'myschool_v2.5.1-1'
git push public myschool_25
git push public --tags
###
# Updating to the next release of Moodle.
git fetch origin
# Make sure that we're on our current 2.5 branch
git checkout myschool_25
# Now create a new branch for 2.6 based on the 2.5 branch
git checkout -b myschool_26
# And we do a rebase where we pick all of the commits since 2.5.0, and place them on top of v2.6.0 instead.
git rebase --onto v2.6.0 v2.5.0
##
# Rinse, wash, repeat.
Note, this isn't the exact strategy that I describe in my blog post, or that we use at HQ, so there may be some issues with that final command because you've merged v2.5.1 and v2.5.2 and ... into your 25 branch but hopefully that should point you in the right direction.
I should also get around to adding some other points which we've found important:
- Giving each site a unique name to make them easily tab-completable
- Keep names short
- Keep capital letters out of your namespace
- Consider using a different namespace using a / as a separator to allow you to fetch a glob - e.g. luvle/* - I'll blog more on this when I get a chance
- Read the git rebase manual
Hope that this helps
Andrew
