Not working with earlier versions of Git

I can't see how the directory structure you describe would work at all. I can't reproduce a problem with submodules. I need actual steps to create a Drupal site that reproduces this issue.

Similar problem here: a D7 site deployed with submodules and currently on core 7.69.

Until 2.2 included, or with git_deploy disabled, the site is correctly detected as 7.69. With 2.3, 2.4 and 2.5, it is detected as "7.x-dev (2018-Jun-26)" instead, and urges to deploy 7.69 although it is the current version. With versions from 2.2 to d2ca3873 (the next one is the incorrect D8 commit and the next is 36d886f as mentioned by OP), however, it works normally.

What may be different from the OP configuration though, is the fact that, for lack of an equivalent to D8 drupal-project, core is deployed as part of the global project repo, so git information for core is irrelevant as it is not about core but about the global project. The only valid sources of information for this type of layout are the actual contents of the core files, and especially the value of the VERSION constant. In this specific case, that value is '7.69'.

I understand caring for all situations is difficult for git_deploy. Maybe site maintainers could help by storing a file with the sha1 for core when core is not itself a git repo ? Or git_deploy could rely on the VERSION constant when git repo information is not reliable ?

I can provide you with a copy of the repo if you want.

A copy of the repo would help with reproducing the issue with submodules. We can address the core issue by only verifying dev versions of core.

I just sent the site repo to you on drupal slack.

I think the issue was fixed in 7.x-2.5. 7.x-2.4 attempted to retrieve tags from the remote repository, which would fail if the web server's shell account did not have the Git credentials. Please try the latest release.

I tested both repositories with 7.x-2.4, 7.x-2.5, and 7.x-2.x-dev, and could not reproduce either missing projects or a change in the core version.

Just checked again with various devs on the production for the repo I sent you, and behaviour changed (WTF ?) on admin/reports/updates:

- 2.2: detects 7.69, reports all contrib code as git submodules cleanly, suggesting git_deploy 2.5
- 2.3, 2.4: detect 7.69, all contrib code as git submodules as missing from the report
- 2.5: detects 7.69, all contrib code as git submodules are now in red "unknown version", with "unsupported" flag, and recommending an update or security update to the latest version (e.g. backup migrate recommended 7.x-3.7, sec update 7.x-3.4), git deploy recommended 2.5, which is the version it is on.
- 2.x HEAD: same as 2.5 except it detects a single contrib module, which happens to be git_deploy, as 7.x-2.x-dev (2020-mai-13), recommending 7.x-2.5.

In all cases, custom modules are reported with no version available, which is the expected behaviour.

Noticing the spelling of the date, I wonder whether this could be an i18n issue, or possibly a git version issue. Server language is fr_FR_UTF8, git version is 2.1.4. System is Jessie 8.11.

Also, FWIW, in another site with a similar layout, some modules are just plain missing while the others are found. I just noticed CTools was not being listed in updates, causing its lack of update to have remained undiscovered for years, and only be detected because it broke with PHP 7.3: it was stuck on a 2016 version. No version of git deploy allows it to be reported on the updates page, although the version is available in the details on admin/modules.

At this point, I think the safest bet is to just use 2.2 until the site eventually si eventually migrated away from D7, if there is no security issue with so doing.

It looks like the rev-parse and merge-base commands are not available in the 1.x branch of Git. Never mind, they do exist. All 1.x branch documentation has been removed from git-scm.com

@hcethatsme that's Git 2.1.4 (latest version on debian jessie) on that server, so Git 1.x is not the only cause.

The PHP expression exec('git -C ' . escapeshellarg(dirname($file->uri)) . ' rev-parse --show-toplevel 2> ' . GIT_DEPLOY_ERROR_DUMP); returns nothing with Git version 1.8.5.6, even though the same Git command returns the expected output when used from a shell.

Finally getting something. Git version 1.8.5.6 is generating an error:

fatal: Failed to expand user dir in: '~/.gitignore'

This error is caused by a Git bug that was fixed in version 2.13.0-rc1.