Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Tracking Moodle CVS with git.

Obsolete:Tracking Moodle CVS with git: Difference between revisions

From MoodleDocs
Line 12: Line 12:


You'll want:
You'll want:
* [http://www.kernel.org/pub/software/scm/git/ Git] (and its deps). It includes '''gitk''', a very good UI for visualising project history.
* [http://git.or.cz/ Git] (and its deps). It includes '''gitk''', a very good UI for visualising project history.
* an additional git porcelain (frontend)
** [http://sourceforge.net/projects/qgit qgit] a nice GUI to view the project history, make commits, etc. Recommended! Note: qgit is tricky to compile by hand, get a .deb or an .rpm
** [http://www.procode.org/stgit/ stgit] (StackedGIT is mainly for users doing heavy cherry picking. Only recommended for very advanced SCM users.)


Git is still developing quickly, but good mature versions are already available in packaged format. This guide is written with GIT v1.5.3 in mind.
You might also find the additional git porcelain (frontend) useful:
* [http://sourceforge.net/projects/qgit qgit] a nice GUI to view the project history, make commits, etc. Recommended! Note: qgit is tricky to compile by hand, get a .deb or an .rpm
* [http://www.procode.org/stgit/ stgit] (StackedGIT is mainly for users doing heavy cherry picking. Only recommended for very advanced SCM users.)
 
Git is still developing very quickly, but good mature versions are already available in packaged format. This guide is written with GIT v1.5.3 in mind.


== Downloading Moodle CVS History for git ==
== Downloading Moodle CVS History for git ==

Revision as of 10:51, 2 October 2008

Note: Work in progress. These are notes for users that are comfortable with CVS and other SCMs, doing branching, merging, etc.

Introduction

If you plan on doing complicated or sustained development on Moodle, you will benefit from a local revision control system. Centralized systems like CVS and SVN have limited capabilities for tracking vendor branches. For the ultimate experience you will want to use a system with distributed capabilities like git. Alternative tools for this include Mercurial, Darcs and SVK.

GIT was developed by Linus Torvalds specifically for the Linux Kernel team. It is fast, fast, fast. Its usage is slightly different from CVS/SVN, but, if kernel developers can handle it Moodle developers will find it easy  ;-)

Git is packaged for most major operating systems and an up to date list of packages can be found on git.or.gz.

Obtaining git

You'll want:

  • Git (and its deps). It includes gitk, a very good UI for visualising project history.

You might also find the additional git porcelain (frontend) useful:

  • qgit a nice GUI to view the project history, make commits, etc. Recommended! Note: qgit is tricky to compile by hand, get a .deb or an .rpm
  • stgit (StackedGIT is mainly for users doing heavy cherry picking. Only recommended for very advanced SCM users.)

Git is still developing very quickly, but good mature versions are already available in packaged format. This guide is written with GIT v1.5.3 in mind.

Downloading Moodle CVS History for git

There are currently two methods of retrieving Moodle CVS history for git:

It is highly advisable to clone the Catalyst git repository as this is updated hourly and the imported CVS history will share common commit hashes allowing developers to merge each others changes easily.

Creating a Working Copy

In order to use your repository you must clone yourself a working copy using git clone.

(Let's assume your destination directory is ~/src/moodle)

git clone git://git.catalyst.net.nz/moodle-r2.git ~/src/moodle

This will clone the catalyst moodle git repostitory into a local working copy that you may make changes to and commit to. You can then get updates from the catalyst git repository that can be merged in amongst the changes to your local copy.

Using git effectively with Moodle

Git can be used to intelligently track changes for creating client installs based off your own local, base, customisations which in turn tracks changes to the main Moodle CVS.

If you have a local git copy of the Moodle CVS repository you will have a number of heads such as: MOODLE_15_STABLE, MOODLE_16_STABLE, and so on. If you wish to create a new branch for your local customisations, you can base it off an existing HEAD (one of the CVS branches that exist in the main Moodle repository). If you wish to create a new local branch, mymoodle, based off the current stable 1.6 code you would:

cd ~/src/moodle
git branch mymoodle origin/MOODLE_16_STABLE
git branch # lists all the current branches, should show mymoodle
git checkout mymoodle # you are now working on the mymoodle branch
# add some new files (i.e. themes, blocks, etc.)
git add  .
git status # Will list your uncommited files
git commit -m "Added base customisations."

To return to the master HEAD, equivalent to the main Moodle CVS HEAD branch, you would have to use:

git branch master

If you were running a nightly script to pull new Moodle CVS updates into your main git repository via git-cvsimport, you should also merge any new changes into your local branch:

cd ~/src/moodle.git
git checkout mymoodle
git merge origin/MOODLE_16_STABLE

If you wanted to use this custom local branch to create a new client install, you could use:

git clone ~src/moodle /home/someclient/public_html/
cd /home/someclient/public_html/
git checkout mymoodle origin/mymoodle

This would create a new git repository from your branch that could be used to do a client install which can, in turn, have the client's custom files added to it. This entire process can be automated so that your mymoodle branch is tracking upstream changes from the Moodle CVS (MOODLE_16_STABLE in this example) and your client installs are tracking changes against your local branch.

Merging a patch from GIT into CVS

If you have cvs access, you can use the git-cvsexportcommit command to merge or cherry pick individual patches into upstream.

git-cvsexportcommit was initially written to do merges of NZOSVLE bugfixes into Moodle. Several tools and patches to GIT and Cogito come from the NZOSVLE team. Martin Langhoff 14:55, 19 July 2006 (WST)

If the patches merge cleanly, future updates will recognise the already-applied patch. In that sense the merger in git is smarter than the merger in Cogito, consider using git-pull rather than cg-update. Note that if you see conflicts using git-pull you will have to work a bit harder to resolve them. Make sure you are familiar with handling merge conflicts with pure git before trying this.

Preparing to merge large patch series or porting over to the next Moodle release

When you have a large set of patches to apply to CVS, or a large set of custom patches to apply on top of the next release of Moodle, you can use git-format-patch to see what are your unmerged patches. git-format-patch tries hard to spot already-merged patches and skip them.

If you are applying patches to CVS, you can then use git-cvsexportcommit or plain old patch -p1 filename. If you are applying them to a new git branch (as you would to merge them on top of a new Moodle release) then you want to be on that new branch, and use git-am -3 -k filename.

If you are using git-am, make sure you learn how to deal with merge conflicts, and the use of git-update-index.

Helpful Documentation

Moodle Forum Discussions