Fix endless loop when multiple remote branches share base with HEAD

Hm, interesting. Looking forward to insights as to why it happens this way.

Could not get it installed on my local as well.

Steps to reproduce:

1. $ git clone http://git.drupalcode.org/project/drupal.git
2. $ git checkout 8.8.5
3. $ composer install
4. $ composer require drupal/git_deploy:^2.0 drupal/upgrade_status:^2.3 -vvv --dev
5. $ php core/scripts/drupal install standard
6. $ drush en git_deploy # Installed successful and quickly. I have had Acquia dev desktop 2 installed, so drush is available globally
7. $ drush en upgrade_status # Have to hit command/ctrl + c to cancel it after more than 2 mins

Or try to install the upgrade_status module from the UI, I tried a fresh installation with Acquia dev desktop 2, and installing the upgrade_status module from the UI, the same -- never-ending.

• PHP 7.3.9
• OS: macOS 10.15.4
• Drush: 9.6.0

Any info in the logs?

$ drush ws
 ---- -------------- ------ ---------- ------------------------------------------------------------------------------
  ID   Date           Type   Severity   Message
 ---- -------------- ------ ---------- ------------------------------------------------------------------------------
  49   20/Apr 15:39   cron   Notice     Cron run completed.
  48   20/Apr 15:39   cron   Notice     Execution of update_cron() took 1839.57ms.
  47   20/Apr 15:39   cron   Notice     Starting execution of update_cron(), execution of system_cron() took 7.25ms.
  46   20/Apr 15:39   cron   Notice     Starting execution of system_cron(), execution of search_cron() took 0.9ms.
  45   20/Apr 15:39   cron   Notice     Starting execution of search_cron(), execution of node_cron() took 7.06ms.
  44   20/Apr 15:39   cron   Notice     Starting execution of node_cron(), execution of history_cron() took 0.6ms.
  43   20/Apr 15:39   cron   Notice     Starting execution of history_cron(), execution of file_cron() took 1.29ms.
  42   20/Apr 15:39   cron   Notice     Starting execution of file_cron(), execution of field_cron() took 0.4ms.
  41   20/Apr 15:39   cron   Notice     Starting execution of field_cron(), execution of dblog_cron() took 0.39ms.
  40   20/Apr 15:39   cron   Notice     Starting execution of dblog_cron(), execution of comment_cron() took 3.26ms.
 ---- -------------- ------ ---------- ------------------------------------------------------------------------------
$ drush en git_deploy
 [success] Successfully enabled: git_deploy
$ drush ws
^C
$ time drush ws
^C

real	1m43.799s
user	1m22.336s
sys	0m16.958s

While trying to show logs to @Gábor Hojtsy with a fresh installation again, found that it looks like it's an issue of git_deploy, not upgrade_status. If this could be reproduced, let's report/move this to git_deploy

Yeah I don't think it's in upgrade status, nothing happens on install in upgrade status. So I was assuming git_deploy gets in a loop.

Figured it out that the git repo structure matters.

1. if the drupal root is the same with the repo root, git deploy does not work as expected -- see the case in #4 / #6
2. if the drupal root is inside a subfolder of the repo root, it works as expected. For example use https://github.com/drupal/recommended-project, the drupal-root is "web/" by default. this is the case i just tested on my local, and it worked for me

If what @VladimirAus reported was the same as me, we should move this issue under git_deploy, or to file a new issue under git_deploy is necessary.

Moving to git_deploy as @Gábor Hojtsy told on slack. Feel free to move back if it is not the same as the one reported by VladimirAus originally.

I'm running into this as well, I'm installing on an existing project using https://github.com/drupal-composer/drupal-project which is similar where the git repo.

Thanks for pointing me at this issue @Gábor Hojtsy

I think I'm having the opposite problem as #8.

My git is outside the drupal root folder:

~/Sites/drupal-git-project/
~/Sites/drupal-git-project/public/

And it just hangs at

[debug] Try to validate bootstrap phase 0 [5.98 sec, 45.41 MB]

Maybe it's a different problem after all... I'll keep in touch

This issue was more clearly reported for the 7.x-2.x branch (#3127208: Fix core version detection when site root is not a Drupal repository), so I am treating that as the parent issue. When that patch passes community review, it can be ported to the 8.x-2.x branch.

Never mind. I found the endless loop. I am testing a fix.

Thanks @Darren Oh that seemed to fix it for me!