discard custom projects in drush up

I did not confirm this but it is new code I think so plausible.

Working fine for me in drush-HEAD.

Are you updating a Drupal-6 or Drupal-7 site? Which modules?

Also can't reproduce with D6 or D7.

That's great! this issue is theorically impossible to happen :D

      // Option 4: no one is a prefix of the other. Find the common
      // prefix by iteratively strip the rigthtmost piece of $path.
      // We will iterate until a prefix is found or path = '.', that on the
      // other hand is a condition theorically impossible to reach.
      do {
        $path = dirname($path);
        if (strpos($path2, $path) === 0) {
          break;
        }
      } while ($path != '.');

To reproduce this we need the output of drush with --debug in order to see what project and modules are involved.
Also,.. now that I remember the patch in #1023120: drush upc rules seems to do something odd make the implied function more fail proof. I'll commit that issue's patch now.

Anyway I'd like to see what's the exact problem to shield that theorically impossible condition.

Not impossible:

php > print dirname(".");
.
php > print dirname("");
php >

There may be others... Anyway, I see that you check for '.', but if $path starts off empty for some reason, that could be the cause of this.

I'm experiencing this with the latest 4.5-dev. I attached a debug log, but it is probably of not much use, as it keeps generating errors indefinitely after bootstrapping.

Here's the list of modules. The site runs 6.x.

In my case the problem was caused by having a custom module and a custom theme installed which both declared "project = 'projectname'" in their .info files. So we had a project containing both a module and a theme (which is probably illegal), and neither were coming from drupal.org.

Custom modules and themes should not declare "project" in their .info files but this happens in the wild when .info files from existing projects are copy/pasted.

so having a module and a theme with the same project name produces a call to drupal_get_path('module', 'the_theme') returning "".

Attached patch does prevent this case by discarding custom projects: those without a project in drupal.org or any kind of external server.

I didn't try this but it seems reasonable to me.

Committed.

Backported.