Git Submodules and Drush temp directories

A limitation here is that pm-download invokes a hook after downloading the project to alter the final install location. See:

    // If user did not provide --destination, then call the
    // download-destination-alter hook to give the chance to any commandfiles
    // to adjust the install location.
    if (empty($destination)) {
      drush_command_invoke_all_ref('drush_pm_download_destination_alter', $request, $release);
    }

I'll try to work something out.

Cool. Looking at that function, I'm a little stumped as to how drush_pm_download_destination_alter would need to work for Submodules. At the moment, it looks like it's purely for handling moving drush commands to an appropriate place, but I'm guessing there's some future use cases as well. If one was attempting to pull a drush related project as a submodule, you will have had to have pulled down drush as a git repo as well. Is this a sticky situation, or am I overthinking things?

I don't think there's an issue, but I'm a little confused by #3. By submodule do you mean an extension (module or theme) that is in a subfolder of a project? drush_pm_download_destination_alter only works for projects; the extensions inside move with the project.

Projects that contain only drush commands are automatically moved to ~/.drush. I think this should work okay with git even if drush was not pulled down via git, but maybe I'm missing something.

Right, we should probably clear up the terminology. So, the submodules we're referring to in this issue are a specific type of git repository - from the git documentation:

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.

So, the submodules here should not be confused with the Drupal concept of submodules, as you mention.

The overall issue is that git submodues MUST be cloned into a location that is already under git's version control. One of the reasons we subverted some of this functionality in our patch (I'm one of the three people with 7sudos, by the way) is because it seems that the concept of pulling via git into an arbitrary temp directory (that may not be a part of the git repo) won't work in many cases when you're dealing with git submodules, which MUST be cloned directly into an existing repo.

Thanks to everyone - does this help to clear up the issue a bit?

Thanks for the clarification about git submodules.

jonhattan is just saying that the proposed code does not take into account a destination_alter hook which usually fires later. once he implements that, this looks committable to me.

I have to say eureka!.

git submodule add git://git.drupal.org/project-stable/devel.git sites/all/modules/devel

is equivalent to:

git clone git://git.drupal.org/project-stable/devel.git sites/all/modules/devel
git submodule add git://git.drupal.org/project-stable/devel.git sites/all/modules/devel

The proposed workflow is to not consider --gitsubmodule a different way to install projects but an extra step after the project has been installed. It does it by implementing hook_drush_pm_post_download().

ps. I found this post of interest to get introduced to git submodules: http://chrisjean.com/2009/04/20/git-submodules-adding-using-removing-and...

I didn’t test this, but the code looks great. I wonder if we should expand hook_drush_pm_post_download() so that we let version control engines participate.

We can commit this as is IMO.

for vc engines: this is part of drush_pm_download():

    // Post download actions.
    drush_command_invoke_all('drush_pm_post_download', $request, $release);
    $version_control->post_download($request);

committed. @7sudos reopen if you get any problem.

Oops, I meant "I wonder if we should expand hook_drush_pm_post_download() so that we let *package handlers* participate. " The gosal is to move git specific code out of pm_drush_pm_post_download and into the git_drupalorg file.

something like package_handler_post_install()? I've used post_install instead of post_download to be in concordance with package_handler_install_project(),.. perhaps both should change to _download

Yes, thats the idea. I do think we should rename both to post_download.

done as of #12. now package-handlers interface is

$ grep ^function commands/pm/package_handler/wget.inc 
function package_handler_validate() {
function package_handler_download_project(&$request, $release) {
function package_handler_update_project(&$request, $release) {
function package_handler_post_download($project) {

On behalf of myself and the rest of 7suods, thanks a million, guys. I'm going to pull and check it out now!