Working with git submodules

The source code for projects like FreeSWITCH and OpenACD imported into the sipXecs project using git submodules. Using git submodules have the following of advantages

1. source code is readily available for developers to work with
2. developers can submit fixes to the projects in sipXecs while their patches make their way upstream to FreeSWITCH and OpenACD projects.
3. release management have greater flexibility on which patches upstream can be back ported to sipXecs based on relevance to sipXecs

Here are some instructions on how to manage submodules.

Pulling in all fixes from upstream project

If you simply want to pull all of the latest fixes from the original projects upstream, then you add a remote branch to the upstream project, then merge the branch into the git submodule. This uses the standard git practice.

Example: Updating OpenACD:

Step 1. From your source root in the sipXecs source tree, select the proper source branch and run the following:

cd OpenACD
git remote add upstream https://github.com/OpenACD/OpenACD.git
git fetch upstream
git branch -t upstream remotes/upstream/master
git checkout master
git merge upstream

Step 2. Change read-only git url to read/write. NOTE: For this step you need sipXecs commit rights.
Edit OpenACD/.git/config and change

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git://github.com/dhubler/OpenACD.git

to

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:dhubler/OpenACD.git

Step 3. You've updated your local copy, but now you need to commit your changes to sipXecs project. These are the same general steps one would follow for submitting any fix to git submodules. This is a two step process: first pushing the changes to the git submodule itself then updating sipXecs to point to that new revision in the submodule.

git push origin master
cd ..
git commit -m 'Updated lastest OpenACD' OpenACD
git push origin master-4.2

Done. Going forward... you can skip the step git remote add... and instead of running git checkout -b upstream upstream/master you can just run git checkout upstream but the rest of the instructions remain the same.

So what you've done by following these steps is to create a way to track and pull in changes from upstream for a given submodule. The sipXecs project has no idea where these changes come from and it doesn't need to care. As such, multiple developers can perform these steps whenever the need arises.