View source for User:Gerard Caulfield/Fast Moodle git setup

[[Category:Git]]

This setup allows you to have multiple working directories while having them all linked and using the same repository which I believe is perfect for Moodle development where you sometimes want to view several versions of moodle at the same time but managing all those instances seperatly is an unnecessary hassle. I've also tried to minimise the amound of time you have to spend waiting for tasks to complete.

==Initial setup==

First create all the necessary directories:
<syntaxhighlight lang="bash">
# Data directories
mkdir -p ~/data/moodle/int/ ~/data/moodle/pro/

# Code directories
mkdir -p ~/src/moodle/int/ ~/src/moodle/pro/

# The seed directory
mkdir ~/src/moodle/.seed/
</syntaxhighlight>

Create a symbolic link in your web root so you can access all of these directories via http://localhost/moodle/ (or whatever location you prefer)
<syntaxhighlight lang="bash">
sudo ln -s ~/src/moodle /var/www/moodle
</syntaxhighlight>

Create the .seed repository for all the other working directories:
<syntaxhighlight lang="bash">
cd ~/src/moodle/.seed/
git init
</syntaxhighlight>
Turn on colorisation and ignore file permission changes
<syntaxhighlight lang="bash">
git config core.ui auto
git config core.filemode false
</syntaxhighlight>
Set yourself as the default author of commits to the repository (you will need to replace the name and email used in the following two example commands)
<syntaxhighlight lang="bash">
git config user.name 'John Doe'
git config user.email johndoe@example.com
</syntaxhighlight>
Add Moodle remotes for Integration and Production (fyi: some people refer to production as "stable", but the word stable is used in integration branche names, so I think production is a better term for this remote). I have added "r_" to the front of the remote names so that there is no ambiguity. Without this in some instances git will not be able to tell if we mean the remote "int" or the folder "int". For the production repository we have used the name "moodle.git", instead of describing it's use case like we did for "integration.git". I can't be sure but I imagine this is done for sites like github, where the repository name is how people find your project, so labeling the repository "production.git" would have make it difficult for people to locate the repository in a search. However I suggest while working on it you think of it as the production repository instead of the moodle repository to keep thing consistent and it's purpose clear.
<syntaxhighlight lang="bash">
git remote add r_pro git://git.moodle.org/moodle.git
git remote add r_int git://git.moodle.org/integration.git
</syntaxhighlight>
If you have a github account you will probably also wish to add a remote for that so you can push changes to it as a public storage location for your changes that you can then link to in Moodle tracker issues. First you need to fork the moodle repository on [https://github.com/moodle/moodle github]. After doing that you can add a remote to it as shown below, remembering to replace yourGithubUsername with your actual github username
<syntaxhighlight lang="bash">
git remote add yourGithubUsername git@github.com:yourGithubUsername/moodle.git
</syntaxhighlight>
If you have a repository that is local to you which contains a copy of moodle you can fetch from that first. The more recent it is the better.
<syntaxhighlight lang="bash">
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/
git fetch local
</syntaxhighlight>
If you did the step above first then git will not need to download any commit objects it already has and so the entire process will go a lot quicker. Fetch everything from the r_int and r_pro repositories. Don't try doing both at the same time as they mostly contain the same data so it may end up trying to download the same thing twice (although I haven't checked). 
<syntaxhighlight lang="bash">
git fetch r_int
git fetch r_pro
</syntaxhighlight>

==The magic part==
Clone some repositories which will help us setup our linked working directories
<syntaxhighlight lang="bash">
cd ~/src
git clone git://github.com/gerrywastaken/git-new-workdir.git
git clone git://github.com/gerrywastaken/MoodeeScripts.git
</syntaxhighlight>
Now, from this point, if you have done everything as instructed you should be able to setup your working directories by running one script
<syntaxhighlight lang="bash">
~/src/MoodeeScripts/setupWorkingDirs.sh
</syntaxhighlight>
==Usage==
Now if you go into any of the directories under '''~/src/moodle/''' each of the working directories will be set to the appropriate version of Moodle and all working directories will be linked to the same '''~/src/moodle/.seed''' repository. These have been created as headless branches so as not to pollute your list of branches with entries like '''MOODLE_22_STABLE''' which will only end up out of date. If you wish to create a new branch or rebase an existing on to a remote branch, it is best to do so directly by first doing a fetch of the remote and then refering to the remote branch using the the following syntax '''<remoteName>/<branchName>'''. Here is an example:
<syntaxhighlight lang="bash">
cd ~/src/moodle/pro/22
git fetch r_pro
# Checkout a new branch based on r_pro/MOODLE_22_STABLE
git checkout -b 22_MDL-946136_change_database_activity_to_use_mongodb r_pro/MOODLE_22_STABLE
# Rebase your current branch to r_pro/MOODLE_22_STABLE
git rebase -i r_pro/MOODLE_22_STABLE
# Checkout a headless branch for testing r_pro/MOODLE_22_STABLE
git checkout r_pro/MOODLE_22_STABLE
# Take a look at the last commit to r_pro/master
git log r_pro/master -n1
</syntaxhighlight>

If you add a branch, remote or commit while in one working directory it will be available to use from all other working directories so you no longer need to repeat yourself as much as if they were all seperate repositories. This means that if you make a change in your master working directory master you can view it from your 2.2 working directory and cherrypick it back by providing the commit ID without needing to do anything else first such as pulling or pushing. There are other scripts in the ~/src/MoodeeScripts which should give you an idea of the ways in which this shared repository setup has advantages over split repositories. It was my intent to polish these scripts up for general consumption, but I ran out of time.

From this point you still need to install each version of Moodle, but that process is well described in many other places.

==Optional==
To make your setup even easier to use you can install zsh and the oh-my-zsh scripts. (Instructious for a ubuntu/debian system)
<syntaxhighlight lang="bash">
sudo apt-get install zsh
chsh -s /bin/zsh
git clone git://github.com/gerrywastaken/oh-my-zsh.git ~/.oh-my-zsh
cd ~/.oh-my-zsh
git checkout moodle
</syntaxhighlight>

Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config
<syntaxhighlight lang="bash">
cp ~/.zshrc ~/.zshrc.orig
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc
</syntaxhighlight>

The screenshot below shows how we would go about checking out a new branch named m_MDL-007_eliminate_bad_guys based on production master (r_pro/master). You will also notice that the current branch is shown on the right hand side (note: headless branches are not displayed, it was something I hoped to address but ran out of time). I then create a file called testfile.txt so you can see the marker which appears if your current banch has uncommited changes. Switching from pro/22 to int/22 is then demonstrated followed by an illustration of one of the advantages of enabling color in git.
[[Image:showingOhMyZsh.png|frame|center|Showing some of the various advantaes of using oh-my-zsh for moodle development]]