Symphony.

Hi all,

This is probably more of a git question than a symphony question, but I figure some folks around here will know what's what.

If I want to create a new project, as its own repo, but use a tracked clone of the Symphony repo as PART of that project (but be able to update Symphony and its submoduled extensions), what's the best way of handling it? Maybe someone has a solid workflow for this process?

What I'm currently doing is just downloading Symphony (without the use of git) and including it as part of the project, so all the symphony files get committed with everything else, functionally this is fine, but it means I can't track or update the symphony files. Extensions are easier to manage, as they're tucked away in their own directory, so those are at least set up properly as submodules.

I find the “Heavyweight: the workspace as a submodule” approach works well for me.

In brief, to start a new project I:

• Checkout Symphony
• Install
• Make a new branch named after my project
• Add extensions as submodules, and commit these additions to my project branch
• Make the workspace directory a submodule as described in that article
• As I develop, make commits to my workspace repo (which is a submodule) and push to my private remote
• Periodically (mostly before I want to deploy updates), I commit the updated workspace submodule to my Symphony project branch

When I want to deploy the project to my servers, I clone my private Symphony repo, checkout the project branch and update all submodules recursively, which brings in the workspace repo and extensions.

If memory serves, when the time comes to update Symphony I switch to the master branch of the Symphony repo to do the update and then merge the updated master branch into my project branch.

Hi David,

That's really helpful. I hadn't even thought of treating the workspace directory as a submodule, and that does indeed make a lot of sense!

Thanks again

You can also just clone the main Symphony repository and add your workspace and extensions to that fork (I think you may have to adjust your .gitignore file in order to do this). If a Symphony update is available you can simply pull the changes in.

If you're cloning the main Symphony repo and you don't want the entire history of Symphony's development you can use git's --depth feature to get a truncated history, so...

git clone --depth 1 https://github.com/symphonycms/symphony-2.git projectname

... will create a fresh clone with only one commit in your new repo (currently the 2.3.6 release commit by Brendan).

I usually do it the way Nils mentions, basically because the extensions and the workspace in themselves are usually pretty much tied up. If I need a new field, probably means I need to add custom extensions etc.

It also creates less of a hassle when trying to release updates, using a workspace submodule will probably mean that you have to commit the change in the submodule, then commit the hash in the main repo, forget one step and your update is not pushed.

If you still like the idea of separate, you could also distinguish the workspace without the submodule, and using a symlink or automated release to the workspace folder, might be more practical from a release perspective.

When creating a shallow clone (e.g.

git clone --depth 1 https://github.com/symphonycms/symphony-2.git projectname

) How do you get around the limitation of not being able to push a shallow clone to your remote repository?

I thought that issue was addressed in git 1.9+ but I'm running 2.0.3 and still getting the same error whenever I set the depth parameter.