Impossible d'exécuter l'éditeur
Je n'ai pas souvent à modifier plusieurs messages de commit, mais c'est arrivé une ou deux fois et je ne me souviens jamais de l'avoir vu. J'espère que quelqu'un d'autre a. Lorsque je git rebase -i HEAD~7, la liste attendue s'ouvre dans vi exactement comme prévu. Je change les valeurs pick en edit le cas échéant, puis :wq.
Résultat: Could not execute editor
Le paramètre core.editor dans mon .gitconfig global est vi (je l'ai également changé en vim dans un mouvement extrêmement désespéré). J'ai essayé d'utiliser mate, mais cela n'a même pas ouvert correctement la liste initiale, aussi je l'ai modifiée.
J'utilise v1.7.3 et serais heureux de recevoir vos suggestions.
Hier n'était qu'un de ces jours. Sur une alouette, j'ai décidé de définir le chemin d'accès complet à vi (par exemple /usr/bin/vi) plutôt que simplement à l'exécutable. Maintenant tout fonctionne. Je dois admettre que je ne l’obtiens pas car vi est parfaitement exécutable tout seul (ma variable $EDITOR env est également définie sur vi), mais cela fonctionne et mon karma technique n’a pas été aussi bon ces derniers temps. 'interrogeons pas les divinités.
La commande suivante
git config --global core.editor /usr/bin/vim
le corrige.
[modifier]
Maintenant, je vois que quelqu'un l'a déjà posté dans les commentaires. J'espère que c'est toujours utile pour certains aveugles comme moi.
Contrairement aux autres réponses données jusqu'ici, utiliser le chemin d'accès absolu vers vi et définir le git core.editor config ne suffisait pas pour résoudre le problème. (Ceux étaient déjà en place.)
Dans ma situation, le problème a été résolu par en ajoutant l'indicateur -f à la commande vi:
git config --global core.editor '/usr/bin/vi -f'
Une fois que cette option -f est en place, je peux utiliser git rebase -i et, lorsque je sauvegarde et quitte la liste de validation, la base est refondue comme il se doit au lieu de donner à l'erreur "impossible d'exécuter l'éditeur".
La page de manuel vim indique l’option -f,
Pour la version GUI, Vim ne va pas séparer du shell dans lequel il a été démarré. Cette option doit être utilisée lorsque Vim est exécuté par un programme qui attend que la session d’édition se termine (par exemple, mail).
Eh bien, je n’utilise pas de version graphique, à ma connaissance. J'utilise git sur la ligne de commande bash dans une fenêtre de terminal sur masOS Sierra 10.12.6. Mais comme git rebase -i attend la fin de la session d'édition, je suppose que c'est pourquoi l'option -f est nécessaire ici. Peut-être que vim (sans -f) essaye de bifurquer/détacher du shell pour une raison quelconque que je n’ai pas pu comprendre.
J'ai eu ce problème, et il a été causé par une partie du plugin vcscommand pour vim. Le démarrage de vim avec l’une de ces commandes a abouti au code de sortie 1 ("erreur"):
vivim
Mais ceux-ci m'ont donné le code de sortie 0 ("succès"):
/usr/bin/vi/usr/bin/vimvi -u NONEvim -u NONE
J'ai été en mesure de remonter au plugin spécifique en désactivant ~/.vimrc et les fichiers dans ~/.vim en les renommant et en exécutant vi -c q ; echo $? pour exécuter rapidement vim et imprimer le code de sortie.
Pour moi, c'était un problème avec mon .vimrc. Renommer temporairement ce fichier a corrigé le problème. Suivi en déboguant mon .vimrc. C'est très similaire à l'expérience de Ignu.
Si vous vouliez utiliser sublime pour quelque raison que ce soit, vous pouvez utiliser l'une des méthodes suivantes dans votre fichier de configuration global:
git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl"
Il m'a juste fallu un certain temps pour retracer mon problème à l'un de mes plugins.
(Plus précisément, il s'agissait de https://github.com/ervandew/supertab )
J'imagine que c'est l'inconvénient de mettre à jour automatiquement tous mes plugins.
Donc, meilleur conseil, désactivez la moitié de votre vimrc et de vos plugins. Si cela ne vous aide pas, le problème vient de votre autre moitié.
J'essayais d'écraser les commits comme indiqué ici https://www.youtube.com/watch?v=V5KrD7CmO4o . Mon éditeur git (notepad ++) s’est ouvert à l’étape de rebasage. Mais, dans l'étape de modification du message, j'ai vu le problème "Impossible d'exécuter l'éditeur". C'est probablement dû au fait que les paramètres de l'éditeur git étaient incorrects et également au fait que j'ai installé notepad ++ dans un emplacement non standard de mon système Windows. C'est-à-dire que 'git config core.editor' m'a donné notepad++ -multilnst- nosession.
Pour résoudre le problème, indiquez le chemin complet comme suit:
git config --global core.editor "'C:\CustomFolder\NPP\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
Une autre option consiste à utiliser l'éditeur nano.
$ whereis nano$ git config --global core.editor path/to/nano
Le fixe.
J'ai eu ce problème aussi alors que j'avais déjà ouvert vim pour un rebase dans un autre terminal. J'avais commencé la réorganisation, je m'étais interrompue et, à mon retour, je l'ai réessayée dans l'autre terminal, sans me rendre compte que j'étais au milieu de la même réorganisation ailleurs. Le fait de terminer la session vim rebase dans l’autre terminal a bien fonctionné.
Êtes-vous sûr que/usr/bin/vim était sur 1.7.3? J'ai eu le même problème parce que j'avais le plugin de sauvegarde installé qui n'est pris en charge que dans la version 1.7.3 et pour une raison quelconque,/usr/bin/vim a été soudainement rétrogradé à la version 1.7.2, peut-être à cause d'une mise à jour majeure de XCode. ..
Pour moi, en utilisant Windows: fermez le terminal actuel et ouvrez-en un autre (win + R, tapez 'cmd', puis 'enter'), puis ça fonctionne soudainement.
Solution VS Code:
git config --global core.editor "/Applications/Visual\ Studio\ Code.app/Contents/MacOS/Electron"
Curieusement, le simple fait d'essayer à nouveau a fonctionné pour moi.
Mes variables core.editor et $ EDITOR ne sont pas définies.