Note: You are currently viewing documentation for Moodle 4.0. Up-to-date documentation for the latest stable version of Moodle may be available here: Git for Administrators.

Git for Administrators: Difference between revisions

From MoodleDocs
(version update)
(Added section about how to upgrade to a newer major release)
Line 3: Line 3:


To get the most of Git it is worth making the effort to understand its basic concepts - see the section below. It can be a bit of a steep learning curve, especially if you are used to CVS or Subversion.  
To get the most of Git it is worth making the effort to understand its basic concepts - see the section below. It can be a bit of a steep learning curve, especially if you are used to CVS or Subversion.  
== Getting hold of Git (Windows, OSX, Linux and others) ==
== Getting hold of Git (Windows, OSX, Linux and others) ==
Support for Git was, up until recently, mostly confined to Linux but builds are now available for most popular operating systems:
Support for Git was, up until recently, mostly confined to Linux but builds are now available for most popular operating systems:
* List of downloads from Git site - http://git-scm.com/download
* List of downloads from Git site - http://git-scm.com/download
Once you have downloaded and installed your OS relevant git installation, the git commands in this document should work with your operating system.
Once you have downloaded and installed your OS relevant git installation, the git commands in this document should work with your operating system.
== Moodle branch names ==
== Moodle branch names ==
Major Moodle versions each have their own branch in Git. For example, MOODLE_38_STABLE (3.8), MOODLE_39_STABLE (3.9). Development is generally done on branch 'master'. The entire lifetime of that version will stay on that branch. Each release is designated by adding a Git 'tag', for example v3.9.0-beta, v3.9.0-rc1, v3.9.0.
Major Moodle versions each have their own branch in Git. For example, MOODLE_38_STABLE (3.8), MOODLE_39_STABLE (3.9). Development is generally done on branch 'master'. The entire lifetime of that version will stay on that branch. Each release is designated by adding a Git 'tag', for example v3.9.0-beta, v3.9.0-rc1, v3.9.0.


Line 19: Line 13:


Do not use alpha, beta, release-candidates or code from the master branch for production sites. It could have significant bugs.
Do not use alpha, beta, release-candidates or code from the master branch for production sites. It could have significant bugs.
== Obtaining the code from Git ==
== Obtaining the code from Git ==
The command line version of Git is discussed here. Graphical clients are little more than wrappers around the command line version, so you should be able to deduce the correct parameters quite easily.  
The command line version of Git is discussed here. Graphical clients are little more than wrappers around the command line version, so you should be able to deduce the correct parameters quite easily.  


Line 43: Line 35:


Note that Git has a huge number of options for each command and it's actually possible to do the above process with a single command (left as an exercise!!).
Note that Git has a huge number of options for each command and it's actually possible to do the above process with a single command (left as an exercise!!).
==Git from behind a firewall==
==Git from behind a firewall==
Git uses a read-only protocol that may be blocked by your firewall (port 9418). If this is a problem, you can use GitHub's http version <nowiki>https://github.com/moodle/moodle.git</nowiki>. It's a bit slower, so use the Git protocol if you can.
Git uses a read-only protocol that may be blocked by your firewall (port 9418). If this is a problem, you can use GitHub's http version <nowiki>https://github.com/moodle/moodle.git</nowiki>. It's a bit slower, so use the Git protocol if you can.
 
== Updating your installation with minor releases ==
== Updating your installation ==
 
The Moodle development team performs integration and testing of fixed bugs every Monday and Tuesday. On Wednesday you can install all patches by updating your code. Check the [http://git.moodle.org/gw?p=moodle.git;a=summary shortlog] to see if the official repository has been already updated or not.
The Moodle development team performs integration and testing of fixed bugs every Monday and Tuesday. On Wednesday you can install all patches by updating your code. Check the [http://git.moodle.org/gw?p=moodle.git;a=summary shortlog] to see if the official repository has been already updated or not.


Line 58: Line 46:
</pre>
</pre>
If this is a production site you should still consider the [[Upgrade]] instructions (e.g. take backups).
If this is a production site you should still consider the [[Upgrade]] instructions (e.g. take backups).
== Upgrading to a newer major release ==
When you want to upgrade to a newer major release, you will need to tell your git installation to track the newer release instead of the release that you currently have installed and are tracking.
You should ensure that you have updated your installation with the latest minor release of your currently installed Moodle version first (as described in the section above). This will also download the changes for newer Moodle versions (but not yet make use of them).
You should put your site into maintenance mode, or disable the website, before starting the upgrade.<syntaxhighlight lang="shell">
cd /path/to/your/moodle/folder
# Check which branch you are currently tracking
git branch -a
# Make a local branch for the newer release from the remote repo
git branch --track MOODLE_400_STABLE origin/MOODLE_400_STABLE
# Switch to track this branch
git checkout MOODLE_400_STABLE
</syntaxhighlight>Your website folder now includes the files for the newer Moodle version, but to complete the Moodle upgrade, you will either need to [[Upgrading|complete the upgrade via the web browser]], or [[Administration via command line|use the command line upgrade script]].


== Installing a contributed extension from its Git repository ==
== Installing a contributed extension from its Git repository ==
This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.  
This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.  


Line 73: Line 76:
</pre>
</pre>
The command (1) changes the current directory into the ''mod'' folder of your local Moodle clone. The command (2) creates a new subdirectory ''certificate'' and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle {{Version}}. The command (4) deletes the ''master'' that was created automatically by git-clone in (2) as we do not want it in this production checkout.
The command (1) changes the current directory into the ''mod'' folder of your local Moodle clone. The command (2) creates a new subdirectory ''certificate'' and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle {{Version}}. The command (4) deletes the ''master'' that was created automatically by git-clone in (2) as we do not want it in this production checkout.
 
Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issuing the command below before running the command (3), in order to verify what is available among the branches:
Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issuing the command below before running the command (3), in order to verify what is available among the branches:
<pre>
<pre>
Line 99: Line 102:
Did you intend to checkout 'origin/MOODLE_31_STABLE' which can not be resolved as commit?
Did you intend to checkout 'origin/MOODLE_31_STABLE' which can not be resolved as commit?
</pre>
</pre>
  Note: To fix above error, use: "git fetch origin MOODLE_31_STABLE:LOCAL_MOODLE_31_STABLE"
  Note: To fix above error, use: "git fetch origin MOODLE_31_STABLE:LOCAL_MOODLE_31_STABLE"
Now it is wise to add the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.
Now it is wise to add the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.
<pre>
<pre>
Line 115: Line 116:
</pre>
</pre>
Writing a shell script with these lines in the root of Moodle installation is a very good idea. Otherwise it is easy to forget what Git repositories are there within the main Moodle repository.
Writing a shell script with these lines in the root of Moodle installation is a very good idea. Otherwise it is easy to forget what Git repositories are there within the main Moodle repository.
== Installing and maintaining contributed extensions using Git submodules ==
== Installing and maintaining contributed extensions using Git submodules ==
As it was said in the previous section, this is for advanced users only.
As it was said in the previous section, this is for advanced users only.
Therefore, it is necessary, that you have some experience with Git and its commands.
Therefore, it is necessary, that you have some experience with Git and its commands.
Line 124: Line 123:
Advanced options and commands can be found at [https://git-scm.com/book/en/v2/Git-Tools-Submodules|the Git book].
Advanced options and commands can be found at [https://git-scm.com/book/en/v2/Git-Tools-Submodules|the Git book].
If you have any questions about Git submodules, please visit the site above first.
If you have any questions about Git submodules, please visit the site above first.
=== Installing a new extension into an existing Moodle ===
=== Installing a new extension into an existing Moodle ===
As an example we use the [[Certificate module]] from the previous section.
As an example we use the [[Certificate module]] from the previous section.
<pre>
<pre>
Line 132: Line 129:
$ git submodule add https://github.com/markn86/moodle-mod_certificate.git mod/certificate
$ git submodule add https://github.com/markn86/moodle-mod_certificate.git mod/certificate
</pre>
</pre>
Note, that Git is reporting two new files in the repository:
Note, that Git is reporting two new files in the repository:
<pre>
<pre>
Line 144: Line 140:
#
#
</pre>
</pre>
The file '''.gitmodules''' contains the local path and url of all your submodules.
The file '''.gitmodules''' contains the local path and url of all your submodules.
It has to be committed, if you intend to clone the repository later (see the page [[Moodle development environment with Git submodules]]).
It has to be committed, if you intend to clone the repository later (see the page [[Moodle development environment with Git submodules]]).
Line 166: Line 161:
   remotes/origin/master          345f5b1 Replaced deprecated function
   remotes/origin/master          345f5b1 Replaced deprecated function
</pre>
</pre>
Git created the branch '''master''' which tracks '''origin/master''' automatically, because the remote repository has checked out '''master'''.
Git created the branch '''master''' which tracks '''origin/master''' automatically, because the remote repository has checked out '''master'''.
Therefore, create a new branch, which tracks the appropriate remote branch.
Therefore, create a new branch, which tracks the appropriate remote branch.
Line 185: Line 179:
$ git commit -a -m "New extension mod_certificate installed"
$ git commit -a -m "New extension mod_certificate installed"
</pre>
</pre>
It has to be ensured, that the commit includes only the changes for the new Git submodule (since '''-a''' commits all non-staged changes).
It has to be ensured, that the commit includes only the changes for the new Git submodule (since '''-a''' commits all non-staged changes).
=== Maintaining Git submodules ===
=== Maintaining Git submodules ===
Maintaining a set of submodules is extremely easy.
Maintaining a set of submodules is extremely easy.
Consider a Moodle repository with several submodules installed.
Consider a Moodle repository with several submodules installed.
Line 223: Line 214:
#
#
</pre>
</pre>
The command '''git submodule foreach [another command]''' walks through all submodule repositiories and executes what is specified by '''[another command]'''.
The command '''git submodule foreach [another command]''' walks through all submodule repositiories and executes what is specified by '''[another command]'''.
In this case it is '''git pull'''.
In this case it is '''git pull'''.
Line 230: Line 220:
$ git commit -a -m "Plugin updates"
$ git commit -a -m "Plugin updates"
</pre>
</pre>
Maintaining plugins with Git submodules has also another application than simplifying the update process.
Maintaining plugins with Git submodules has also another application than simplifying the update process.
In a greater scale it can be used to maintain a Moodle project, where multiple developers need to have an exact copy of your moodle without organizing external plugins manually.
In a greater scale it can be used to maintain a Moodle project, where multiple developers need to have an exact copy of your moodle without organizing external plugins manually.
You can read more about this topic at the page [[Moodle development environment with Git submodules]].
You can read more about this topic at the page [[Moodle development environment with Git submodules]].
== See also ==
== See also ==
* [[Windows installation using Git]]
* [[Windows installation using Git]]
* [[Git for Mac]]
* [[Git for Mac]]
Line 242: Line 229:
* For fixing a Tracker Issue (MDL) / Forking Moodle / CONTRIButing code [[:dev:User:Sam Hemelryk/My Moodle Git workflow|User:Sam_Hemelryk/My_Moodle_Git_workflow]]
* For fixing a Tracker Issue (MDL) / Forking Moodle / CONTRIButing code [[:dev:User:Sam Hemelryk/My Moodle Git workflow|User:Sam_Hemelryk/My_Moodle_Git_workflow]]
* [[Moodle Production Server with GIT|Case study Git + Moodle from Technical University Berlin]]
* [[Moodle Production Server with GIT|Case study Git + Moodle from Technical University Berlin]]
; Moodle forum discussions
; Moodle forum discussions
* [https://moodle.org/mod/forum/discuss.php?d=255175 Github and Moodle deployment for production]
* [https://moodle.org/mod/forum/discuss.php?d=255175 Github and Moodle deployment for production]
Line 248: Line 234:
* [https://moodle.org/mod/forum/discuss.php?d=231046 Clear git guide for Admins (not developers)]
* [https://moodle.org/mod/forum/discuss.php?d=231046 Clear git guide for Admins (not developers)]
* [https://moodle.org/mod/forum/discuss.php?d=393756 Best way to use Git]
* [https://moodle.org/mod/forum/discuss.php?d=393756 Best way to use Git]
; External resources  
; External resources  
* [http://thamblings.blogspot.com.au/2013/07/upgrading-moodle-from-git.html Deploying Moodle from git - Blog post from a production experience]
* [http://thamblings.blogspot.com.au/2013/07/upgrading-moodle-from-git.html Deploying Moodle from git - Blog post from a production experience]
* [http://gitref.org/ Git Reference]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]
* [http://progit.org/book/ Pro Git book]
[[ja:管理者用Git]]
[[ja:管理者用Git]]
[[fr:Git pour administrateurs]]
[[fr:Git pour administrateurs]]
[[es:Git para Administradores]]
[[es:Git para Administradores]]
[[en:Git für Administratoren]]
[[en:Git für Administratoren]]

Revision as of 15:39, 27 May 2022

This page describes how to maintain a copy of Moodle on your production server which can easily be upgraded using Git. If you have customisations of Moodle core code, you are advised to follow the instructions in the Git for developers guide.

To get the most of Git it is worth making the effort to understand its basic concepts - see the section below. It can be a bit of a steep learning curve, especially if you are used to CVS or Subversion.

Getting hold of Git (Windows, OSX, Linux and others)

Support for Git was, up until recently, mostly confined to Linux but builds are now available for most popular operating systems:

Once you have downloaded and installed your OS relevant git installation, the git commands in this document should work with your operating system.

Moodle branch names

Major Moodle versions each have their own branch in Git. For example, MOODLE_38_STABLE (3.8), MOODLE_39_STABLE (3.9). Development is generally done on branch 'master'. The entire lifetime of that version will stay on that branch. Each release is designated by adding a Git 'tag', for example v3.9.0-beta, v3.9.0-rc1, v3.9.0.

Important: Even though the branch name has 'STABLE' in it, it does not mean that the code on that branch is actually stable. Soon after the branch is made it will contain 'beta' and 'release candidate' versions of the new Moodle version. It's important to check that the current state of the branch meets your needs. Generally, the easiest way is to examine the current contents of version.php - substitute the branch in this url, https://github.com/moodle/moodle/blob/MOODLE_39_STABLE/version.php

Do not use alpha, beta, release-candidates or code from the master branch for production sites. It could have significant bugs.

Obtaining the code from Git

The command line version of Git is discussed here. Graphical clients are little more than wrappers around the command line version, so you should be able to deduce the correct parameters quite easily.

You can find the official Moodle git repository at git://git.moodle.org/moodle.git (with an official clone at git://github.com/moodle/moodle.git). To initialize your local checkout, use

$ cd /path/to/your/webroot
$ git clone git://git.moodle.org/moodle.git                       (1)
$ cd moodle
$ git branch -a                                                   (2)
$ git branch --track MOODLE_400_STABLE origin/MOODLE_400_STABLE     (3)
$ git checkout MOODLE_400_STABLE                                   (4)
  • The command (1) initializes the new local repository as a clone of the 'upstream' (i.e. the remote server based) moodle.git repository. The upstream repository is called 'origin' by default. It creates a new directory named moodle, where it downloads all the files. This operation can take a while as it is actually getting the entire history of all Moodle versions
  • The command (2) lists all available branches.
  • Use the command (3) to create a new local branch called MOODLE_400_STABLE and set it to track the remote branch MOODLE_400_STABLE from the upstream repository.
  • The command (4) actually switches to the newly created local branch.

Git Connection Refused Error

fatal: unable to connect to git.moodle.org: git.moodle.org[0: 34.210.133.53]: errno=Connection refused

Note that Git has a huge number of options for each command and it's actually possible to do the above process with a single command (left as an exercise!!).

Git from behind a firewall

Git uses a read-only protocol that may be blocked by your firewall (port 9418). If this is a problem, you can use GitHub's http version https://github.com/moodle/moodle.git. It's a bit slower, so use the Git protocol if you can.

Updating your installation with minor releases

The Moodle development team performs integration and testing of fixed bugs every Monday and Tuesday. On Wednesday you can install all patches by updating your code. Check the shortlog to see if the official repository has been already updated or not.

To update your code to the latest version (on the MOODLE_400_STABLE branch) all you have to do is:

$ cd /path/to/your/moodle/
$ git pull

If this is a production site you should still consider the Upgrade instructions (e.g. take backups).

Upgrading to a newer major release

When you want to upgrade to a newer major release, you will need to tell your git installation to track the newer release instead of the release that you currently have installed and are tracking. You should ensure that you have updated your installation with the latest minor release of your currently installed Moodle version first (as described in the section above). This will also download the changes for newer Moodle versions (but not yet make use of them).

You should put your site into maintenance mode, or disable the website, before starting the upgrade.

cd /path/to/your/moodle/folder

# Check which branch you are currently tracking
git branch -a

# Make a local branch for the newer release from the remote repo
git branch --track MOODLE_400_STABLE origin/MOODLE_400_STABLE

# Switch to track this branch
git checkout MOODLE_400_STABLE

Your website folder now includes the files for the newer Moodle version, but to complete the Moodle upgrade, you will either need to complete the upgrade via the web browser, or use the command line upgrade script.

Installing a contributed extension from its Git repository

This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.

For example, let us say we want to install the Certificate module from its Git repository into our Moodle 4.0.

$ cd /path/to/your/moodle/
$ cd mod                                                          (1)
$ git clone https://github.com/markn86/moodle-mod_certificate.git certificate     (2)
$ cd certificate
$ git checkout -b MOODLE_400_STABLE origin/MOODLE_400_STABLE        (3)
$ git branch -d master                                            (4)

The command (1) changes the current directory into the mod folder of your local Moodle clone. The command (2) creates a new subdirectory certificate and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle 4.0. The command (4) deletes the master that was created automatically by git-clone in (2) as we do not want it in this production checkout.

Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issuing the command below before running the command (3), in order to verify what is available among the branches:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/MOODLE_20_STABLE
  remotes/origin/MOODLE_21_STABLE
  remotes/origin/MOODLE_22_STABLE
  remotes/origin/MOODLE_23_STABLE
  remotes/origin/MOODLE_24_STABLE
  remotes/origin/MOODLE_25_STABLE
  remotes/origin/MOODLE_26_STABLE
  remotes/origin/MOODLE_27_STABLE
  remotes/origin/MOODLE_28_STABLE
  remotes/origin/MOODLE_29_STABLE
  remotes/origin/MOODLE_30_STABLE
 remotes/origin/MOODLE_31_STABLE
  remotes/origin/master

This will avoid an error message when you issue the command (3) against a nonexistent branch, e.g.:

§ git checkout -b MOODLE_31_STABLE origin/MOODLE_31_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_31_STABLE' which can not be resolved as commit?
Note: To fix above error, use: "git fetch origin MOODLE_31_STABLE:LOCAL_MOODLE_31_STABLE"

Now it is wise to add the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.

$ cd /path/to/your/moodle/
$ echo /mod/certificate/ >> .git/info/exclude

To update your Moodle installation now, you must visit both Git repositories and pull changes from upstream.

$ cd /path/to/your/moodle/
$ git pull
$ cd mod/certificate
$ git pull

Writing a shell script with these lines in the root of Moodle installation is a very good idea. Otherwise it is easy to forget what Git repositories are there within the main Moodle repository.

Installing and maintaining contributed extensions using Git submodules

As it was said in the previous section, this is for advanced users only. Therefore, it is necessary, that you have some experience with Git and its commands. A step-by-step explanation will be provided, but in order to follow these steps it is helpful to understand, what these commands do.

Advanced options and commands can be found at Git book. If you have any questions about Git submodules, please visit the site above first.

Installing a new extension into an existing Moodle

As an example we use the Certificate module from the previous section.

$ cd /path/to/your/moodle
$ git submodule add https://github.com/markn86/moodle-mod_certificate.git mod/certificate

Note, that Git is reporting two new files in the repository:

$ git status
# On branch MOODLE_29_STABLE
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   .gitmodules
#	new file:   mod/certificate
#

The file .gitmodules contains the local path and url of all your submodules. It has to be committed, if you intend to clone the repository later (see the page Moodle development environment with Git submodules). Before commiting, make sure to check the configuration of the plugin's Git repository, since the automatically generated settings may be not sufficient. For future updates it is helpful, to track the remote branch, which corresponds to the Moodle version of your repository.

$ cd mod/certificate
$ git branch -avv
* master                          345f5b1 [origin/master] Replaced deprecated function
  remotes/origin/HEAD             -> origin/master
  remotes/origin/MOODLE_20_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_21_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_22_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_23_STABLE fe047de Check that the function exists rather than relying on the Moodle version
  remotes/origin/MOODLE_24_STABLE 1051f7d CONTRIB-4892 Fixed the email to others functionality
  remotes/origin/MOODLE_25_STABLE cdb221a CONTRIB-4946: Removed character from language file breaking AMOS
  remotes/origin/MOODLE_26_STABLE 696802a Increased version
  remotes/origin/MOODLE_27_STABLE d3c0379 Increased version
  remotes/origin/MOODLE_28_STABLE fa8df83 Increased version
  remotes/origin/MOODLE_29_STABLE 3f03740 Replaced deprecated function
  remotes/origin/master           345f5b1 Replaced deprecated function

Git created the branch master which tracks origin/master automatically, because the remote repository has checked out master. Therefore, create a new branch, which tracks the appropriate remote branch. Of course, this is only possible, if the remote repository offers those branches.

$ git checkout -b MOODLE_29_STABLE origin/MOODLE_29_STABLE
Branch MOODLE_29_STABLE set up to track remote branch MOODLE_29_STABLE from origin.
Switched to a new branch 'MOODLE_29_STABLE'
$ git branch -D master
Deleted branch master (was 345f5b1).

It is not necessary to delete the master branch, but it's useless to keep it. In fact, these settings don't need to be touched afterwards.

The final step is to commit the changes to the main repository.

$ cd /path/to/your/moodle
$ git commit -a -m "New extension mod_certificate installed"

It has to be ensured, that the commit includes only the changes for the new Git submodule (since -a commits all non-staged changes).

Maintaining Git submodules

Maintaining a set of submodules is extremely easy. Consider a Moodle repository with several submodules installed. Keep in mind, that the extension mod_mylittleextension is a fake plugin, created for a test scenario in this example. It is not an official Moodle module. For updating all your submodules at once, type in:

$ cd /path/to/your/moodle
$ git submodule foreach git pull
Entering 'block/coursefeedback'
Already up-to-date.
Entering 'mod/certificate'
Already up-to-date.
Entering 'mod/mylittleextension'
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From /local/repositories/mle
   89d9eae..64c122d  master     -> origin/master
Updating 89d9eae..64c122d
Fast-forward
 index.html  |    9 +++++++++
 version.php |    6 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)
 create mode 100644 index.html
$ git status
# On branch MOODLE_29_STABLE
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   mod/mylittleextension (new commits)
#

The command git submodule foreach [another command] walks through all submodule repositiories and executes what is specified by [another command]. In this case it is git pull. Therefore, the module mylittleextension was updated and the main repository isn't clean anymore until changes are committed:

$ git commit -a -m "Plugin updates"

Maintaining plugins with Git submodules has also another application than simplifying the update process. In a greater scale it can be used to maintain a Moodle project, where multiple developers need to have an exact copy of your moodle without organizing external plugins manually. You can read more about this topic at the page Moodle development environment with Git submodules.

See also

Moodle forum discussions
External resources