So all my extensions are empty dirs, flagged as fatal bad object.
What am I missing?

Did you run git submodule update --init?

Have you initialised them?

was just reading progit, indeed I needed to init to actually get the extensions into their directories, however in gitx view the source keeps:
fatal: bad object 09fdb57bbb4c0494c52bde00523929b029a627b4:extensions/debugdevkit But I guess this is normal?

Also when cloning larger ensembles, it hangs after a while, resulting in a bunch of empty extesnions after that:

Submodule path 'extensions/profiledevkit': checked out '634d75cef26c5b70628b7b5aa604541301c1bfc2'
Cloning into extensions/publish_tabs...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Clone of '' into submodule path 'extensions/publish_tabs' failed

I found out this was because it runs into submodules with an url path formated like:

rather then:


Could anyone clarify the theory behind this, and why these paths end up in a public repo? Does this simply mean that these extensions were cloned on github between parties giving each other permission to do so, rather then locally, since they use an an ssh URL ?

as explained here on SO

I can easily open the .gitmodules file and edit the paths, but the edit doesnt stick. Do I need to branch first? How to make the edits stick on my local clone?

edit: deleted, sorry, i didn't quite understand what you were asking.

i've had to edit .gitmodules to replace the git urls as well, but i've never had a problem with them not sticking.

It appears the ensemble you're trying to use was made by nickdunn (or somebody else who has write-access to nickdunn/publishfiltering).

The URL is a read/write-access URL, but only for the people who have permission to do so. The git:// URL is for readonly-access, even if you're using the service anonymously.

So apparently, the person creating the ensemble was able to use the read/write-URL in his repository. Other people (like you) are not allowed to use that URL, hence the error message.

To replace it you have to edit two files: .gitmodules and .git/config. As always, run git submodule update --init afterwards.

thanks phoque, I succeeded in replacing it by your instructiosn. Now when I clone the emsemble from my desktop into a localhost directory, again it loses the edits.
What is the proper way of copying the ensemble into one I start to work with? Ofcourse I want to keep the original ensembel intcat to revert to.

BTW if anyone knows of an advanced GIT tutorial specific to symphony and extensions, I am happy to hear about it. The Getting Git for Symphony Development article is really to limited.

from my desktop into a localhost directory, again it loses the edits.

So you changed that stuff on a local repository and cloned it into another local repo in your computer? Weird... did you commit anything inbetween?

Can you tell us which ensemble this is you're cloning? I haven't heard of a remote repo storing the paths as git@ yet, but I'm intrigued to see it and find a workaround.

If you're cloning an ensemble, then why not just clone into your localhost directly? Once there make a second branch for your development, and set that one as your upstream to your repo on github (if you're remotely storing your project).

I'm in the middle of researching and writing an article for Symphony and extensions/submodules at the mo, it will be submitted to the docs working group for consideration when the draft is done.

Here's an excerpt from my article (altered), it may help:

  1. Clone the ensemble repo, set the origin to ensemblerepo and get the master branch only

    git clone -o ensemblerepo -b master git:// your-localhost-dir
    cd your-localhost-dir
  2. Add your project's remote repo.

    git remote add yourrepo
  3. Push the project to your empty repo, to give it some structure and content.

    git push yourrepo master
  4. Set the upstream for the master branch, pointing to your project's repo.

    An upstream is just a term to say that your branch is "downstream" from the remote, which is "upstream" from yours, making the remote the master repo of the branch.

    git branch --set-upstream master yourrepo/master
  5. Create and checkout a new branch for the ensemble, starting at the master branch.

    git checkout -b ensemble master
  6. Set the upstream for the ensemble branch, pointing to the ensemble repo.

    git branch --set-upstream ensemble ensemblerepo/master
  7. Once you've done all this, if you need to pull from the ensemble, just switch to the ensemble branch, pull and switch back.

  8. Then just git merge master ensemble to merge the ensemble's updates. If there are any conflicts, you'll have to correct them. I've not got to this in Git yet as I haven't coma across it yet.


indeed, and I didn't commit anything


I am cloning fawx html5 ensemble, working on a readymade html5 ensemble as you proposed me ;-) over here

indeed, and I didn't commit anything

Maybe you had to. You know, tell Git what the URLs are. I'm guessing here :-)

I am cloning fawx html5 ensemble, working on a readymade html5 ensemble as you proposed me ;-) over here

hehe, cool...

Has any of this helped?

on my end, when i cloned my own ensemble, it was asking for my rsa keyphrase any time it got to one of the extensions that was listed in .gitmodules. this is my very first git project, so i'm not sure of the significance of this, but i went ahead and adjusted the submodule urls to use git:// rather than i'm not exactly sure how they were saved that way (perhaps if i use the read-write url when doing submodule add?), but i hope this sheds some light.

@newnomad i've pushed the changes to github. feel free to send me pull requests as well! i'd love to see this turn into something awesome.

@ designermonkey

Yes it has, but currently I am limiting it to local git. What I am still trying to get my head around is - as you can read on the ensemble thread- on how to make sure that a forked or cloned (difference?) framework can be updated/merged on my local install by a new version after I have made modification in it (implementation or operating -wise). On github one forks and then clones, but locally I directly clone, I guess, yet the remote thing does make it upgradable?...

@ fawx, thanks, as soon as I get it ;-)

@ designermonkey

How is your article coming along?

Life seems to have taken a front-burner at the mo, I'll try and get back to it a the weekend hopefully...

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details