git-for-drupal workflow - git submodules

Here is the structure that we currently use for Drupal projects:

• drupal/: core files (git submodule), modified to have profiles and sites a symlink to ../profiles and ../sites
• profiles/: project-specific installation profiles
• sites/: sites directory
  • all/modules/contrib: one submodule per contrib module (pointing to the release repositories on drupal.org
  • all/modules/custom: custom modules, directly in the repository
• docs/: project documentation
• config/: deployment configuration

Subscribe. That's pretty similar to what I've been thinking I'll do for a multisite install that gets moved around a few development servers, and production sites might be split between a few servers.

I'm thinking I'll also use submodules for themes in /sites/all/themes/xxx, and stuff in /sites/all/libraries/xxx.

Just wondering whether anyone thinks its worthwhile to bother with stuff like /sites/xxx/modules/xxx and /sites/xxx/themes/xxx as submodules, or just stick with one repository for the site at /sites/xxx ? I haven't yet had to deal with the git-mechanics of, say, reverting to an earlier version of a single custom theme for a site, while keeping other custom themes and site-specific modules. But I know I will.

Is this similar to what this tutorial is talking about.

http://www.simonhanmer.com/using_git_control_drupal_multi_site_setup

I am interested in figuring this out too.

Is it possible to include only a partial tree from a git repository as a submodule?

@_double: I don't actually know if Git supports that or not. Are you asking because you're worried about pulling in all of contrib? That's not how Git on d.o is going to work. Each contrib project will have a separate repo, so if you have a submodule pointing to Views, you only get Views. Not sure why you'd want a partial tree given this configuration...

Putting in the appropriate project

I would advice anyone to stay far far away from submodules as you can get into very nasty problems when removing, merging or in any other way moving or altering them. I've used them quite a lot myself and they are nice when they do work (and when people do remember to initialize them) but when they don't you're in a complete mess.

In a multisite drupal I would add all of the individual sites as repos of them own and through a gitignore in the main drupal repo ignore every single site.

For contrib modules I would add these as subtrees by using git-subtree: http://github.com/apenwarr/git-subtree

@voxpelli

Thanks for the useful input. I am trying to establish a best-practice workflow for git + multisite in D7.

::

Subscribe.

Moving to the docs queue.

subscribe

subscribing

Based on this advice I looked at git-subtree and haven't looked back. Once you're set up, the workflow is as simple as git-subtree push -P path/to/module remoterepo branch to push commits elsewhere, and substitute pull in place of push to merge from upstream. Compared to submodules, it's ludicrously simple. You just have to ensure each commit you make is module-specific (which it should be, anyway) so that they can be split off cleanly.

subscribing

I am really not sure if I am on the right thread so I ask you to forgive me if I am not and if you do know where I can have some further information, please give me some pointers.

We are migrating the Brazilian Public Software Portal into Drupal and we are already experiencing with the International Public Software Portal in this link: http://spi.softwarepublico.gov.br

We want the projects hosted in our portal to use our git repository and I am trying to find a couple of things:

1. a single-signon solution for both Drupal 7 and git
2. a git browser module
3. a github connector

Can you give me some clues?

Use the forums for support requests - http://drupal.org/forum - you are more likely to find help by posting a forum topic.

Done! Thank you!