User:Gerard Caulfield/Fast Moodle git setup: Difference between revisions
David Mudrak (talk | contribs) m (Text replacement - "<code bash>" to "<syntaxhighlight lang="bash">") |
David Mudrak (talk | contribs) m (Text replacement - "</code>" to "</syntaxhighlight>") |
||
| Line 15: | Line 15: | ||
# The seed directory | # The seed directory | ||
mkdir ~/src/moodle/.seed/ | 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) | 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"> | <syntaxhighlight lang="bash"> | ||
sudo ln -s ~/src/moodle /var/www/moodle | sudo ln -s ~/src/moodle /var/www/moodle | ||
</ | </syntaxhighlight> | ||
Create the .seed repository for all the other working directories: | Create the .seed repository for all the other working directories: | ||
| Line 26: | Line 26: | ||
cd ~/src/moodle/.seed/ | cd ~/src/moodle/.seed/ | ||
git init | git init | ||
</ | </syntaxhighlight> | ||
Turn on colorisation and ignore file permission changes | Turn on colorisation and ignore file permission changes | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
git config core.ui auto | git config core.ui auto | ||
git config core.filemode false | 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) | 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"> | <syntaxhighlight lang="bash"> | ||
git config user.name 'John Doe' | git config user.name 'John Doe' | ||
git config user.email johndoe@example.com | 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. | 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"> | <syntaxhighlight lang="bash"> | ||
git remote add r_pro git://git.moodle.org/moodle.git | git remote add r_pro git://git.moodle.org/moodle.git | ||
git remote add r_int git://git.moodle.org/integration.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 | 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"> | <syntaxhighlight lang="bash"> | ||
git remote add yourGithubUsername git@github.com:yourGithubUsername/moodle.git | 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. | 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"> | <syntaxhighlight lang="bash"> | ||
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/ | git remote add local /media/myUsbDrive/prettyOldMoodleRepository/ | ||
git fetch local | 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). | 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"> | <syntaxhighlight lang="bash"> | ||
git fetch r_int | git fetch r_int | ||
git fetch r_pro | git fetch r_pro | ||
</ | </syntaxhighlight> | ||
==The magic part== | ==The magic part== | ||
| Line 63: | Line 63: | ||
git clone git://github.com/gerrywastaken/git-new-workdir.git | git clone git://github.com/gerrywastaken/git-new-workdir.git | ||
git clone git://github.com/gerrywastaken/MoodeeScripts.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 | 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"> | <syntaxhighlight lang="bash"> | ||
~/src/MoodeeScripts/setupWorkingDirs.sh | ~/src/MoodeeScripts/setupWorkingDirs.sh | ||
</ | </syntaxhighlight> | ||
==Usage== | ==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: | 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: | ||
| Line 81: | Line 81: | ||
# Take a look at the last commit to r_pro/master | # Take a look at the last commit to r_pro/master | ||
git log r_pro/master -n1 | 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. | 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. | ||
| Line 95: | Line 95: | ||
cd ~/.oh-my-zsh | cd ~/.oh-my-zsh | ||
git checkout moodle | git checkout moodle | ||
</ | </syntaxhighlight> | ||
Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config | Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config | ||
| Line 102: | Line 102: | ||
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc | cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc | ||
source ~/.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. | 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]] | [[Image:showingOhMyZsh.png|frame|center|Showing some of the various advantaes of using oh-my-zsh for moodle development]] | ||
Latest revision as of 20:24, 14 July 2021
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:
# 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/
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)
sudo ln -s ~/src/moodle /var/www/moodle
Create the .seed repository for all the other working directories:
cd ~/src/moodle/.seed/
git init
Turn on colorisation and ignore file permission changes
git config core.ui auto
git config core.filemode false
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)
git config user.name 'John Doe'
git config user.email johndoe@example.com
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.
git remote add r_pro git://git.moodle.org/moodle.git
git remote add r_int git://git.moodle.org/integration.git
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 github. After doing that you can add a remote to it as shown below, remembering to replace yourGithubUsername with your actual github username
git remote add yourGithubUsername git@github.com:yourGithubUsername/moodle.git
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.
git remote add local /media/myUsbDrive/prettyOldMoodleRepository/
git fetch local
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).
git fetch r_int
git fetch r_pro
The magic part
Clone some repositories which will help us setup our linked working directories
cd ~/src
git clone git://github.com/gerrywastaken/git-new-workdir.git
git clone git://github.com/gerrywastaken/MoodeeScripts.git
Now, from this point, if you have done everything as instructed you should be able to setup your working directories by running one script
~/src/MoodeeScripts/setupWorkingDirs.sh
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:
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
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)
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
Backup your zsh config file and overwrite it with the .oh_my_zsh template and then reload the zsh config
cp ~/.zshrc ~/.zshrc.orig
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc
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.
