Closed (won't fix)
Project:
Drush
Version:
8.x-6.x-dev
Component:
PM (dl, en, up ...)
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
16 Dec 2011 at 00:17 UTC
Updated:
11 Sep 2013 at 05:07 UTC
Jump to comment: Most recent file
Comments
Comment #1
rfayAfter #1314554: dl --destination sets a relative path for project_install_location lands, this still remains an issue, easily recreatable on MacOS Lion.
Comment #2
moshe weitzman commentedI'm on Leopard at the moment instead of Lion and git 1.7.8.3. Cannot reproduce. Please post the the full log here when run with --debug.
It would be good to know if the downloaded module is already in the reference cache when this bug is triggerred.
Comment #3
rfayI turned off caching completely and rebuilt my repo without the caches as described in git clone --reference considered harmful, which, of course, was an outcome of your mention of the reference cache :-)
Attached is the log of a drush dl; After the dl I have this on a git status:
Comment #4
moshe weitzman commentedWow, thats quite a 180 on reference cache. --cache is off by default for git_drupalorg so folks won't be getting it unknowingly. They do get it when they do a drush make without --working-copy which is pretty neat IMO. They aren't ending up with .git dirs anyway so it makes sense to turn on --cache by default.
As for this submodule bug, I dunno. I probably won't look into it more myself but hopefully someone will.
Comment #5
greg.1.anderson commentedI have used
$options['cache'] = TRUE;to good effect; my normal workflow does not bring me into any of the dangerous territory. The blog post is great, though; best to be sure everyone is forewarned; it was almost a coincidence more than a plan that I had no trouble.Here is a suggested documentation patch for examples.drushrc.php to alert users to the potential issues.
Comment #6
greg.1.anderson commentedn.b. #5 does not address the issue with --gitsubmodule, so perhaps it should have been a separate issue.
Comment #7
moshe weitzman commentedCommitted the docs patch. I actually removed pm-clone because it was too thin and awkward of an alias without its --cache . And the new docs are a little awkward since they suggest making a global 'cache' option, instead of command-specific. I did not change this though.
Moving this to active so someone can look into submodule problem.
Comment #8
opdaviesI'm having a similar issue, although I'm doing this directly on my remote web server running CentOS. I've cloned Pressflow 6 from Github which worked fine. I've made the following amends to my drushrc.php file so that it uses Git submodules by default.
I've downloaded admin_menu using the following command, and this seems also to work fine as the module is in the correct place.
However, my .gitmodules file says something different:
There is now also an additional 'all' directory within the root of this installation that also contains a modules/admin_menu directory that contains a README.txt file and a .git file.
This doesn't happen if I add a submodule using the usual Git method.
[root@homer pressflow]# git submodule add --branch 7.x-3.x git://git.drupal.org/project/views.git sites/all/modules/viewsComment #9
opdaviesI've tried this on a Ubuntu virtual machine and can confirm that I don't get the issue then.
Comment #10
opdaviesI've changed my git clone code slightly, and now it seems to be working OK on Mac OS X Lion. This could, of course, be a coincidence - but I can't think of anything else that I've changed.
No luck with CentOS yet though. :(
Original:
git clone git://git.drupal.org/project/drupal.git httpdocs
New:
git clone http://git.drupal.org/project/drupal.git httpdocs
Comment #11
rfay@opdavies, it sounds like you're off topic. And I assume you mean "git clone". There should be no difference whatever in what protocol you use for accessing the git repository.
Comment #12
opdaviesYes, 'git clone' of course (I've updated my original post).
It just seems strange that it's working for me now on OS X Lion when it wasn't before and that's the only thing that I can think of.
Comment #13
rfayJust a note that this problem remains in current lastest in master branch. It will eventually become important enough for action as people use Lion and git submodule, I imagine.
Comment #14
jonhattanI'm using git 1.7.10 on debian testing and can't reproduce.
Drush adds the downloaded project as a submodule in
package_handler_post_download(), atcommands/pm/package_handler/git_drupalorg.incFor a project downloaded to
sites/all/modules, the sequence used to obtain the superproject path is:It comes from #999480: Git Submodules and Drush temp directories. Previously,
git rev-parse --git-dirwas used instead ofgit rev-parse --show-toplevel.If I'm in the track --show-toplevel gives you a relative path and perhaps --git-dir is the option we need.
Comment #15
rfayI'm wondering if this is actually a git version problem. If so I think it will show up on other platforms before long.
I happened to notice an item on stackexchange that pointed to a git mailing list discussion (I think) talking about confusion with "modules" directory and git.
So I updated to git 1.7.10.4, and the symptoms have changed somewhat.
Now the drush dl'ed submodule gets added to
l/modules/<modulename>Comment #16
rfayI decided to see if this was related to the git version, so built git 1.7.7.2, which is a longstanding version working (well) with drush on Ubuntu 10.04.
But the behavior and the l/ directory is the same.
Note that drush explicitly adds the submodule in the l/ directory. Why is that?
Comment #17
jonhattanDrush fails to get the full path of the superproject. Please can you post the output of
git rev-parse --show-toplevelandgit rev-parse --git-dirfrom/tmp/drupal/sites/allper #14 ?Comment #18
rfayThanks for looking, @jonhattan
#17:
Comment #19
jonhattanis /tmp a symlink or what's going on?
if you intersect this:
you get
l/modulesso the submodule path isl/modules/viewsComment #20
jonhattanspecifically:
For reference: http://api.drush.org/api/drush/commands%21pm%21package_handler%21git_dru...
Comment #21
rfayIt's a MacOS thing. /tmp is a symlink to /private/tmp
So I did it in ~/tmp instead, and lo and behold, with the old git (1.7.7.2) drush dl --package-handler=git_drupalorg works fine:
Now works also with 1.7.10.4:
Now with git 1.7.8.4, which is the version that has dogged me for months...
I ALSO can't recreate the problem in this simple environment:
Comment #22
rfayOK, maybe we're making progress here, and maybe someday we'll understand this.
I use ~/workspace/sitename normally, but on my MacOS env, ~/workspace is a symlink to ~/Documents/workspace
So taking the exact same repo we've been working with and putting it in ~/workspace, we have the fail again:
Ah finally, some closure on this! It turns out to have to do with symlinked parend directories, probably not MacOS. Here's the exact same thing in the same directory (but not using the symlink). Now it's in ~/Documents/workspace:
Retitling to indicate the actual source of the problem.
Updated the issue summary.
Comment #22.0
rfaySimply minor finesse.
Comment #23
jonhattanReplicated in Debian:
log:
Note that the directory it tries to add as submodule depends on the strlen of the directory and the symlink.
Attached a simple fix.
Comment #24
rfayWorks for me.
Thanks so much for hanging with me on this long-term issue. Sure glad you mentioned the symlink back in #19.
Comment #25
jonhattanI'm reluctant to commit this fix by now. We need tests to cover several scenarios with symlinks, and perhaps the fix here is other: to use realpath'ed paths since early stages.
* #1539760: Drupal root getting miscalculated when sites dir is a symlink
* #721064: Remove dangerous getcwd() and use drush_cwd() instead
I'll write some tests in short.
Comment #26
moshe weitzman commentedComment #27
luksakMarking #1716832: Git submodules don't work when having Drupal core in a subfolder as a duplicate.
Comment #28
luksakWorks perfectly! Thank you sooo much!!! ;)
Comment #29
moshe weitzman commentedComment #30
greg.1.anderson commentedThis issue was marked
closed (won't fix)because Drush has moved to Github.If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to
closed (duplicate).Please ask support questions on Drupal Answers.
Comment #30.0
greg.1.anderson commentedUpdated to mention a symlink problem, not a MacOS problem.