Cannot run program "git" (in directory "/"): error=2, No such file or directory

SubGit
#1

I’m looking at log files for some git repositories to investigate an issue which was reported by one of our developers.

At daemon* logs, there are exceptions about git command: “Cannot run program “git” (in directory “/”): error=2, No such file or directory”
When I check dependencies of .deb package, git doesn’t seem to be a dependency for subgit_3.3.5_all.deb to be installed.
I’m using subgit in a docker container which is pulled from dockerhub as a gitlab omnibus installation. Inside container, when I execute git --version, it works:

root@gitlab:~# git --version
git version 2.16.3
root@gitlab:~#

Questions:

  1. Why subgit can’t use git command, although it seems to be installed? What can I do to get rid of this exception?
  2. Is this exception important to be payed attention? Does ignoring this exception make my svn -> git sync unhealthy?
#2

There’s an option
{code}
[core]
gitPath = /path/to/git/executable
{code}
( https://subgit.com/documentation/config-options.html#core.gitPath )

By default its value is just “git”, i.e. without path, i.e. “git” from PATH.

The option does the following: it allows SubGit to execute Git command. Mostly the command is used to read Git objects. Before starting using the Git executable specified (“git” from PATH is the default value, as I wrote), it checks whether it’s a usable Git command at all by running “git --version” using “/” as the working directory:
{code}
[2019-04-24 09:05:36.835][daemon][16] Executing [git, --version]; environmentVariables={};workingDirectory=/
[2019-04-24 09:05:36.836][daemon][16] Git command specified is not usable
[2019-04-24 09:05:36.836][daemon][16] Cannot run program “git” (in directory “/”): error=2, No such file or directory
{code}
And in your case SubGit decides that the Git command is not usable and falls back to reading Git objects using internal Java code (which is slower and requires more memory but still operational).

So the error message above is just a warning, not a critical error.

But in either case I would recommend you to check why you can’t run “git” from PATH from “/” as working directory on behalf of the system user “git” (GitLab uses “git” system user to run Git hooks). Possible reasons are:

  1. “git” system user doesn’t have Git executable in its PATH environment variable.
  2. “git” system user doesn’t have permissions to run programs from “/” directory (e.g. doesn’t have “+x” permission for it).

Possible solutions:

  1. Ignore the warning.
  2. Specify full path to the Git executable in ‘core.gitPath’ option and run “subgit install” to apply the change.
  3. Make sure “git” system user can run programs from “/” directory.

For completeness I should add that there’re other scenarios when “git” executable could be used by SubGit. E.g. see https://subgit.com/documentation/config-options.html#svn.triggerGitGC option (it triggers Git garbage collector every N revisions). In absence of the Git executable, the option would be just ignored.

Meanwhile we’ll try to reproduce the problem (thanks for your detailed description!). If you manage to make “git” executable work, please tell us what was the problem.

#3

Thanks, for the detailed explanation and help. I’ve entered into docker container and made some tests with these information:

[root@gitlab ~]# docker exec -it gitlab /bin/bash
root@gitlab:/# java -version 
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-0ubuntu0.16.04.1-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)
root@gitlab:/# which git
/opt/gitlab/embedded/bin/git
root@gitlab:/# ls -l /opt/gitlab/embedded/bin/git
-rwxr-xr-x. 1 root root 2443024 May 23  2018 /opt/gitlab/embedded/bin/git
root@gitlab:/# su - git -c "git --version"
-su: 1: git: not found
root@gitlab:/# su - git -c "/opt/gitlab/embedded/bin/git --version"
git version 2.16.3
root@gitlab:/#

It seems that the reason is:

  1. “git” system user doesn’t have Git executable in its PATH environment variable

It has “+x” permission but can not be run as, simply git, by the user “git”. In order to get benefit of other features and optimization, I’ll apply the option:

  1. Specify full path to the Git executable in ‘core.gitPath’ option and run “subgit install” to apply the change.

I think it will solve the problem since su - git -c "/opt/gitlab/embedded/bin/git --version" works.

Thanks @dmitry.pavlenko and all the TMate team. You’ve made our migration (and also life) easier with Subgit! :)