Looking to get the Mifos source code? You've come to the right place. Instructions on getting, and contributing to, the Mifos source code through our Git repository can be found below.
Effective use of version control is critical to effective team collaboration on Mifos. Our version control system is how we communicate code changes with one another.
Download a snapshot
- Download the latest code without version control
If you want to do download source code of some previous release then you should browse the repository and use "snapshot" link to download that code as a tar.gz archive.
Please follow this section completely before cloning any Mifos repositories.
1. Install Git
The following sections outline how to install git on Windows, Ubuntu and the Mac OS:
Installing Git on Windows:
- Install msysGit (look for a file named similarly to
- select default components
- in "Adjusting your PATH environment" select "Run Git from the Windows Command Prompt"
- choose the default for the "Configuring the line ending conversions": "Checkout Windows-style, commit Unix-style line endings"
Installing Git on Ubuntu:
sudo apt-get install git-core
You may also find Step 4 of the Ubuntu install guide to be a handy reference.
Installing Git on Mac OS:
To install using macports, follow instructions here.
Alternately, an installer (.dmg) can be found at git's web site. (This .dmg file has been found to work just fine on Snow Leopard as well, despite being labeled as for Leopard.)
2. Configure Git line endings
Tell Git to handle line endings for you so folks on different platforms can live in harmony.
Configure line endings on Windows:
Do this on the Git Bash MINGW msysGit command line:
git config --global core.autocrlf true
Configure line endings on Linux or Mac OS:
git config --global core.autocrlf input
More information on line endings is available at the following URLs:
3. Configure Git Author Info
To make all commits clear/legible/accessible, please configure git to use your full, real name and email.
user.name must be your real/legal first and last name. Do not abbreviate either. If you have more than two names, pick the two you are most commonly known by.
git config --global user.name "Joe Example"
user.email must be a working email address. This address should be permanent, ie: not something that will change when you change jobs.
git config --global user.email email@example.com
4. Clone the codebase (read-only)
This is basically similar to a checkout operation - you'll get a read-only personal copy of the source code, which you can examine and modify as you like.
In the following example, we clone the "head" repository, but you can clone any of the repositories listed at https://github.com/mifos (also see below for tables explaining purposes of the various repositories).
git clone git://github.com/mifos/head.git
Mifos business intelligence code.
Code related to the Mifos cloud.
Mifos documentation and various files that don't belong in head.
Most work on the Mifos MIS Java Web application happens here. Many development branches exist. Mifos release maintenance branches are also found in head, one for each release since 1.6.x.
Maven-related code used for building code in the head repository.
Mifos plugins. Projects in this repository build plugins to assist with imports of various kinds of transactions into Mifos.
Code for mifos.com and mifos.org.
A spike on a complete Mifos rewrite. Mostly incorporated into head.
Static version of Mifos UI used during a Summer of Code 2010 CSS redesign project.
An old spike.
"master" in this repository is an old (1.4.x) release maintenance branch. See head for code for 1.6.x and later releases.
"master" in this repository is an old (1.5.x) release maintenance branch. See head for code for 1.6.x and later releases.
5. Fork the repository
To obtain a personal copy of the source code, which you can immediately commit to, head to Github (http://www.github.com/) and create an account there. You can fork the main Mifos repository by:
git clone firstname.lastname@example.org:username/head.git
Add the Mifos repository as the upstream repository (the repository the fork came from):
git remote add upstream git://github.com/mifos/head.git
If, whilst you've been inspecting the code or making changes, other commits have been made to the Mifos repository that you cloned, you can pull in upstream changes from the original repository with:
More help is available here: https://help.github.com/articles/fork-a-repo
6. Commit to a local repository
Add files to the git "index" so they will be committed with "git add". Optionally, instead of running "git add", include -a when running "git commit" to commit all local modifications except new files. Then, commit:
In Git, the first 80 characters of the first line are, by convention, a summary of the rest of the log message. See Commit Log Guide.
7. Push your changes to a remote repository
If the remote repository is called "origin", you might do:
8. Update your master branch
git pull --rebase origin master
Using rebase is recommended to keep the commit history graph clean. Specifically, trivial merges cause a great deal of clutter. We may eventually institute a server side hook to prevent trivial merges.
9. Creating a patch
Instead of forking the Mifos repository you want to contribute to, you can create a patch. Here are two suggestions:
1) Create an emailable (or JIRA-attachable) patch from your last local commit:
git format-patch origin/master
2) If you have a public git repository, create a pull request, with for example something like this:
git request-pull -p 5e5303a9328b4e620c58ec1f69fbb2118077d594 git://github.com/vorburger/mifos-head.git
Either way, send the output to the mifos-developer mailing list, and describe your patch following Commit Log Guide.
You can also action the pull request via the Github user interface - just update the Mifos bug ticket with a helpful notification. For example:
Submitted in github pull request #x (pending).
Please refer to Pro Git: Basic Branching and Merging.
Creating a local branch
git branch NAME_OF_BRANCH
Deleting a local branch
git branch -d NAME_OF_BRANCH
Local branches can be listed with:
To see all "remote" branches:
Note that "remote branch" really means a local copy of a remote branch.
Merging in changes from another branch
git checkout BRANCH_TO_MERGE_CHANGES_TO
git merge OTHER_BRANCH
Resolving merge conflicts
The release tag naming convention is simply the exact version number of the release. This tag should be created on the release branch/fork. The tag should be GPG-signed by a Mifos maintainer.
Example done for the 1.5.0 release:
git tag -s 1.5.0 f32b705f09b879bc91324f31cbcbff87637d9fb3
git push --tags origin
Hudson automatically tags commits as they are built. These are currently only stored locally in Hudson's clones. It might be convenient to automatically propagate these tags elsewhere.
Where to get more help
Eclipse IDE Integration
EGit provides "Team" (version control) capabilities in Eclipse.
EGit does not yet support comparing full trees.
For Mifos administrators and curious contributors
- vibrant community
- mature, stable toolkit
- got help from former Mifos volunteer and git user Tom Bostelmann
- separate committer and author fields
Legacy version control
Mifos source code was originally hosted in Subversion. Not everything was imported from Subversion. Neither git-svn nor svn2git could parse Svn 1.5+ mergeinfo, so multiple branches could not be imported simulataneously.
We chose to create multiple git repositories on sf.net, one for every long-lived release branch. Development branches may still be created and shared according to the above documentation.
How to migrate a Subversion branch to Git
Locally, pull down a branch from Subversion:
mkdir mifos-1.5.x && cd mifos-1.5.x
git svn init https://mifos.svn.sourceforge.net/svnroot/mifos/branches/v1.5.x
git svn fetch
This will take a while. While this is running, create a new git repository at sf net for the branch you are about to copy from Subversion.
Once the pull from svn is complete, you can then push to sf.net:
git remote add origin ssh://email@example.com/gitroot/mifos/1.5.x
git push origin master
There may be an interim period where the bridge between Subversion and Git must be kept alive. Subversion and Git commits can coexist in "head". To grab the latest from svn and push it to "head":
git svn fetch
git merge remotes/git-svn
git push origin master
To move your changes past all svn changes in your local git-svn clone, do:
git svn rebase
git push origin master
If you lose your original git-svn clone of, say, /branches/1.5.x, you can do the following to hook a clone of the 1.5.x repo back up to the corresponding branch in svn:
git config svn-remote.svn.url https://mifos.svn.sourceforge.net/svnroot/mifos/branches/v1.5.x
git config svn-remote.svn.fetch ':refs/remotes/git-svn'
Then try rebase/push as mentioned above.
All hook scripts used on the sf.net repositories are committed to resources/scripts/githooks in head.
Here's what I did for the cia.vc pinger scripts:
- manually copied them into sf.net shell, "~" directory via scp
- SSH'd into sf.net shell
- copied scripts into /home/scm_git/m/mi/mifos/head/hooks/
- from "hooks" dirs of other projects, symlinked to the hook scripts in the "head" hooks dir (so only one version of the scripts needs to be maintained)
Note that the "update" script uses a different path to ciabot.bash than you'd expect based on the git repository paths on sf.net when you SSH in (the repositories aren't in /home/scm_git when the hook scripts are executing).
The "hooktest" repository can be used for testing hook scripts. If "hooktest" is missing, a new empty repository can be created.
Backups are done using the git client (to maintain bare clones of repositories at sf.net) and rsync (to maintain files that aren't cloned). They are staged in /home/gitbackup on the backup server.
The gitbackup user performs backups daily as follows:
set -o errexit
for repodotgit in `\ls $HOME/repositories/mifos`
repo=`basename $repodotgit .git`
git fetch --quiet git://mifos.git.sourceforge.net/gitroot/mifos/$repo > /dev/null
cd - > /dev/null
rsync --archive --delete --relative \
See also: http://kerneltrap.org/mailarchive/git/2010/5/20/30749
Test restores were performed by copying the backup back to sf.net and cloning.
We moved from sf.net to github https://groups.google.com/forum/#!topic/mifosdeveloper/ksIORnLVHlA/discussion|https://groups.google.com/forum/#!topic/mifosdeveloper/ksIORnLVHlA/discussion