0

I need to switch from Composer (which is used by Symfony2 by default) to Git submodules. I thought I could just add the desired submodules to the desired locations, thus overwriting the current version which was installed by Composer.

But when I use git submodule add, it says:

'vendor/twig/twig' already exists in the index

So I tried:

git rm vendor/twig/twig

and tried to add the submodule again, same error.

What am I doing wrong?

pst
  • 1,414
  • 11
  • 22
Andresch Serj
  • 35,217
  • 15
  • 59
  • 101
  • Could you maybe explain the background, why do you need to move to submodules instead of composer? – m0c Aug 27 '12 at 14:51
  • Did you remove the `vendor` directory before to add your submodules? If the directory exists, it won't add the submodule. – William Durand Aug 27 '12 at 15:14
  • As **@WilliamDURAND** said, try to run `rm -rf vendor/` before adding the submodules. – Florent Aug 27 '12 at 15:18
  • @m0c: The cloud service does not support Composer and only let's me push via git. So if i push, the vendors do not get pushd as well. – Andresch Serj Aug 27 '12 at 16:07
  • Simply using git submodules doesn't seem to work since the composer seems to handle the autoloading :( – Andresch Serj Aug 28 '12 at 11:22

3 Answers3

3

I'm founder and ceo of cloudControl. Currently composer does break our image building process because it interferes with the logic we have to detect submodules in some way. The team is aware of this problem and working to fix the underlying issue.

pst
  • 1,414
  • 11
  • 22
2

I'm working for cloudControl and we've been lately inquiring into this issue. Regarding the original problem, you proposed already a right solution for replacing the composer packages by git submodules, it was just a git commands issue. But doing this doesn't make much sense, as long as these git submodules are identical to the Composer packages and your php code is still hanging on the autoload.php provided by Composer.

We don't process internally Composer yet, their files are just added into the repository and the php code requirements make the rest. However we do process git submodules, so if you want to make a real switch from Composer to Git Submodules, the best option is getting rid of Composer files (vendor folder and composer.* files), adding git submodules wherever you want and handling again the php dependencies . Thus everything should work fine and you'd have switched completely to git submodules.

Native support for Composer is in our future plans.

Fernando Á.
  • 7,295
  • 7
  • 30
  • 32
  • i don't quite understand: I only use the Composer Component as a general autoloader now, which should work fine. Where i store the git submodule should be irrelevant shouldn't it? – Andresch Serj Aug 29 '12 at 11:12
  • Yes, you can totally keep using Composer, git submodule or both together, but keep in mind that autoloader.php just handle automatically the packages added by Composer itself. Anyway you can edit these requirements anytime you want. – Fernando Á. Aug 29 '12 at 11:25
  • sure, but i can use the autoloader_namespaces file to add my submodules easily. what is the alternative? is there a special autoloader for submodules? – Andresch Serj Aug 29 '12 at 11:35
  • 1
    There isn't as far as I know, so you're doing right editing autoload_namespaces by yourself, it should work indeed, as long as you point to the right paths of your submodules. – Fernando Á. Aug 29 '12 at 11:42
1

The problem was that i had to actually delete and git-remove the repository first.

i.e. for twig what i did in the end was:

git rm -r vendor/twig/*
rm -r vendor/twig/*
git add vendor/.
git submodule add git://github.com/fabpot/Twig.git vendor/twig/twig
git submodule add https://github.com/fabpot/Twig-extensions.git vendor/twig/extensions

Now i have twig and twig extensions as a git submodule and can use it in my cloud application.

Andresch Serj
  • 35,217
  • 15
  • 59
  • 101