Reputation: 2911
I've done a fair bit of searching on this but none of the results quite hit the nail on the head.
$ mkdir blah
$ git init
$ git submodule add -b 7.x http://git.drupal.org/project/drupal.git drupal
$ git submodule add -b 7.x-1.x http://git.drupal.org/project/devel.git drupal/sites/all/modules/contrib/devel
I then get the error:
The following path is ignored by one of your .gitignore files:
drupal/sites/all/modules/contrib/devel
Use -f if you really want to add it.
So I add the -f parameter...
$ git submodule add -f -b 7.x-1.x http://git.drupal.org/project/devel.git drupal/sites/all/modules/contrib/devel
... but, after cloning into the right place, I get this error:
fatal: Path 'drupal/sites/all/modules/contrib/devel' is in submodule 'drupal'
Failed to add submodule 'drupal/sites/all/modules/contrib/devel'
I'm working on the principal that once I have all the submodules checked into place, I could just do a "git clone --recursive
" on the 'container' repo, which would then grab Drupal, all my "contrib" modules (from the Drupal repository) + any custom modules I would add into drupal/sites/all/modules/custom
. I still need to research if it's possible to automatically get the submodule to be an appropriate checked out tagged release...
I've seen posts about git-slave (a 3rd party addon) and git-subtree (which looked like something to do with adding all your submodules into branches and merging them into place?!)...
I just feel like I'm missing something as this is something SVN could do REALLY easily and yet everyoen seems to struggle with using Git...
Upvotes: 2
Views: 984
Reputation: 53
This is a super old question but .. The reason you can't do exactly what you've tried to do is that git only stores a special "gitlink" file type to store the pointer to the referenced repository (actually to a specific commit) and knows absolutely nothing about the files within that repository. As a result the directory within your initial submodule reference doesn't exist as far as the superproject is concerned, and in fact is blocked off from being used in the git index as it's reserved for use by the submodule.
The way we do this is to create a project that uses the drupal repository as a starting point. We add drupal projects as submodules of the base repository.
git clone http://git.drupal.org/project/drupal.git drupal
cd drupal
# add submdoules inside the original drupal repository
git submodule add http://git.drupal.org/project/devel.git sites/all/modules/contrib/devel
# even better drush does this for you (but might require you install git_deploy first):
drush dl devel --package-handler=git_drupalorg --gitsubmodule
# commit
git commit -m"Add devel module"
You can change the remote or add a new remote, and push there:
git remote set-url origin [email protected]/my-project.git
git checkout -b my-branch-name
git push -u origin my-branch-name
And clone elsewhere with --recursive:
git clone --recursive [email protected]/my-project.git
The big difference from what you've tried to do is that Drupal's root is the root of the git repository instead of a subfolder at ./drupal. You could add this customized drupal project as a submodule of another superproject if you needed to have version tracked files in a directory above the drupal root. As long as you clone with --recursive it will recurse into submodules of submodules as one would expect.
That said, doing heavy development on both a superproject and a subproject in the same working space can be troublesome as you need to commit and push the submodule as well as update and commit the superproject or remote checkouts will be missing needed references, so I'd recommend leaving the drupal root as the root if possible.
Upvotes: 1
Reputation: 239
I hate to answer your question with an answer you dont want but you might consider basing your projects on a drush make files (and add that file to your git repo while ignoring yor contrib module directory.
This way you track only the changes to your module verions and not all of th eoriginal code itself which drupals git repos will do for you and drush will pull down. I've found it alleviates the need to use git submodules almost entirely while still discretely tying the current state of my site to the contributed modules themselves without mucking up my diffs.
Upvotes: 1