2
votes

'submodule' semble être une commande git, mais nous n'avons pas pu l'exécuter

J'ai cloné un référentiel git, c'est une application ASP.NET Angular 7, tout va bien dans le projet, mais lorsque j'essaye de restaurer des packages npm, j'obtiens l'erreur ci-dessous.

Sous-module
\ Microsoft \ TeamFoundation \ Team Explorer \ Git \ cmd \ git.EXE mise à jour - q --init --recursive fatal: 'submodule' semble être une commande git, mais nous ne l'étions pas capable de l'exécuter. Peut-être que git-submodule est cassé? à ChildProcess.exithandler (child_process.js: 291: 12) à ChildProcess.emit (events.js: 182: 13) à peut-êtreClose (internal / child_process.js: 961: 16) à Process.ChildProcess._handle.onexit (internal / child_process.js: 248: 5) npm ERR! cb () jamais appelé!

Package.json

{
 "name": "name",
 "version": "6.1.1",
 "license": "......",
 "scripts": {
   "ng": "ng",
   "start": "ng serve --open",
   "start-hmr": "ng serve --configuration hmr -sm=false",
   "start-hmr-sourcemaps": "ng serve --hmr -e=hmr",
   "build": "node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --dev",
   "build-stats": "node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --dev --stats-json",
   "build-prod": "node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --prod",
   "build-prod-stats": "node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --prod --stats-json",
   "test": "ng test",
   "lint": "ng lint",
   "e2e": "ng e2e",
   "bundle-report": "webpack-bundle-analyzer dist/stats.json"
},
"private": true,
"dependencies": {
  "@agm/core": "1.0.0-beta.3",
  "@angular/animations": "6.0.5",
  "@angular/cdk": "6.2.1",
  "@angular/common": "6.0.5",
  "@angular/compiler": "6.0.5",
  "@angular/core": "6.0.5" 
},
"devDependencies": {
  "@angular-devkit/build-angular": "0.6.8",
  "@angular/cli": "6.0.8",
  "@angular/compiler-cli": "6.0.5",
  "@angular/language-service": "6.0.5",
  "@angularclass/hmr": "2.1.3",  
  "typescript": "2.7.2",
  "webpack-bundle-analyzer": "2.13.1"
  }
}

Ma version-nœud installée est 10.7.0 et npm-version est 6.4.1

J'ai trouvé sur GitHub des problèmes comme celui-ci et ils ont ajouté un correctif dans npm-lifecycle, j'ai donc installé le npm-lifecycle mais j'obtiens toujours la même erreur

npm node.js visual-studio npm-install git

1 commentaires

Je ne sais pas si c'est le problème, mais dans la commande que vous avez collée, il y a un espace à l'intérieur de l'option '-q'

3 Réponses :

5
votes

La commande submodule n'est pas intégrée au binaire de base git.exe , elle est implémentée sous la forme d'un script shell nommé git-submodule , qui doit être accessible à partir de % PATH% , et être exécutable pour l'utilisateur qui exécute l'action.

Quel est votre % PATH% (ou le % PATH% pour votre processus npm)?
Inclut-il le chemin de votre installation git, qui semble se trouver quelque part dans \ Microsoft \ TeamFoundation \ Team Explorer \ Git \ ?
L'utilisateur qui exécute le processus npm a-t-il des droits d'exécution sur git-submodule ?

4 commentaires

comment puis-je trouver ces chemins? Je pense qu'il n'y a aucun problème avec l'utilisateur parce que je cours en tant qu'administrateur.

pour afficher votre variable d'environnement PATH: echo% PATH%

Je peux voir le chemin npm comme C: \ Users \ name \ AppData \ Roaming \ npm et le chemin du nœud comme `C: \ Program Files \ nodejs`, maintenant ce que je dois faire exactement pour corriger ce problème? lorsque je restaure npm, il télécharge tous les packages mais la fin du téléchargement j'obtiens l'erreur et les dépendances ne sont pas restaurées.

Sous Windows, vous devez pointer sur le sous-dossier "bin". Par exemple, dans mon cas, c'était "C: \ Program Files \ Git \ bin"

-1
votes

Vous n'avez probablement pas installé Git pour Windows. Ce que j'ai fait, et cela semble avoir fonctionné pour moi, c'est d'ouvrir le programme d'installation de Visual Studio, puis de choisir de "modifier" l'installation actuelle et depuis l'onglet "Composants individuels" j'ai coché "Git pour Windows" (qui n'a pas été coché) .

Après l'installation, je n'ai plus eu la même erreur.

1 commentaires

Bien sûr, j'ai installé Git probablement que vous n'avez pas bien lu la question, les 6 premiers mots de la question sont ma réponse à votre réponse et en fait le problème était lié au chemin. :)

1
votes

Git 2.24 (Q4 2019) corrigera une cause possible de ce message d'erreur, vu sous Windows.

Voir commit 4e1a641 (24 août 2019) par Adam Roben ( aroben ) .
^{(fusionné par Junio C Hamano - gitster - dans commit 6f21347 , 30 septembre 2019)}

mingw : correction du lancement d'externals à partir de chemins Unicode

Si Git a été installé dans un chemin contenant des caractères non ASCII , commandes telles que git am et git submodule , qui sont implémentées comme externes, échouerait à démarrer avec l'erreur suivante:
fatal: 'am' appears to be a git command, but we were not able to execute it.  
Maybe git-am is broken?
Cela était dû au fait que lookup_prog n'était pas compatible avec Unicode. C'était en quelque sorte manqué dans 85faec9 (Win32: prise en charge des noms de fichiers Unicode (sauf dirent code>), 15/03/2012, Git v2.1.0-rc0).

Notez que le seul problème dans cette fonction était l'appel GetFileAttributes () au lieu de GetFileAttributesW () .
Les appels à access () étaient très bien car access () est une macro qui résout en mingw_access () , qui gère déjà correctement Unicode.
Mais lookup_prog () a été changé pour utiliser _waccess () directement afin que nous ne convertir le chemin en UTF-16 une fois.

Pour que les choses fonctionnent correctement, nous devons maintenir les versions UTF-8 et UTF-16 en tandem dans lookup_prog () .

0 commentaires

'submodule' semble être une commande git, mais nous n'avons pas pu l'exécuter

Package.json

mingw : correction du lancement d'externals à partir de chemins Unicode

`mingw` : correction du lancement d'externals à partir de chemins Unicode