Ошибка: «git:« submodule »не является командой git» в Ubuntu 18.04.4 LTS и git 2.18.1
Я пытаюсь использовать подмодуль git с git, но при запуске
$ git submodule update --init --recursive
я получаю
git: 'submodule' is not a git command. See 'git --help'.
Я не могу найти решение онлайн, кроме этого вопроса Ошибка: «git:« submodule »не является командой git» в Intel Edison и git 2.0.1 , что не работает в моем случае.
Ранее я установил git из apt-get метод. Я столкнулся с этой проблемой. Теперь я собрал Git из исходного кода, как упомянуто здесь , но я пропустил часть
Для того, чтобы иметь возможность добавлять документацию в различных форматах (doc, html, info), эти дополнительные зависимости необходимы :
$ sudo dnf установить asciidoc xmlto docbook2X
$ sudo apt-get установить asciidoc xmlto docbook2x
, поскольку мне это не нужно. Как мне с этим справиться?
1 ответ
Running sudo apt update followed by sudo apt install git installs git from Ubuntu's repositories. This build of git has a working submodule command. I recommend installing git that way, unless you have a specific reason to do otherwise.
Although you should be able to build git from source code in such a way that git submodule works, for most people the best way to install git on Ubuntu is to install the Ubuntu package for it. The package is simply called git. It supports the submodule command.
Also, do try finding which git client might be troubling you. Run type git to locate it. Then remove this version and reinstall git.
To install the git package, run:
sudo apt update
sudo apt install git
git submodule works for me on an 18.04 LTS system on which git was installed that way.
(There is also a git-all package, which installs additional tools and services. Those instructions suggest it, but I don't think most users ever need anything beyond what the git package provides. It won't hurt anything to install it, but if you just install git you can still install git-all later. The 18.04 LTS system on which I just tested git submodule does not have the git-all package, or most of its dependencies, installed.)
When a newly installed version of a program should offer new behavior but unexpectedly behaves the same as what you had before, often the cause is that what you had before is still running, rather than the new software. The type command can help diagnose this. Based on further investigation of your problem, that strongly appears to be what is going on.
When you ran type -a git, it revealed that you had multiple installations of git and that the one that was actually running (/home/.../linux-devkit/sysroots/x86_64-arago-linux/usr/bin/git) was different both from the one installed through Ubuntu's package manager and the one you recently installed from source.
If you don't need that one, it may be best to uninstall it. If you do need it, or cannot remove it for some reason -- and also in the mean time, before you do remove it -- you can work around the problem by ensuring that the directory that contains a properly working git executable appears in $PATH before that one.
If it is acceptable to put /usr/bin in $PATH before /home/.../linux-devkit/sysroots/x86_64-arago-linux/usr/bin, that will solve the problem.
But that might not be acceptable. Perhaps you're relying on other executables being found first in that other bin directory. In that case, you could put a symlink to /usr/bin/git in some other directory that is earlier in your $PATH than that.
I recommend that approach over further breaking that git installation by renaming or deleting specific files such as /home/.../linux-devkit/sysroots/x86_64-arago-linux/usr/bin/git. The reason is that git has multiple executables, as some git commands are provided externally to the main git executable. Renaming (or deleting) some but not others could cause a situation where you're running one version of git that uses pieces of another version of git. This would probably work okay most of the time, but it would be complicated to troubleshoot when it didn't.