Impossible d'exécuter l'éditeur

Je n'ai pas souvent à modifier plusieurs messages de validation, mais cela s'est produit une ou deux fois et je ne me souviens jamais avoir vu cela. J'espère que quelqu'un d'autre l'a fait. Lorsque I git rebase -i HEAD~7, la liste attendue s'ouvre dans vi exactement comme prévu. Je change les pickvaleurs en le editcas échéant, puis :wq.

Impossible d'exécuter l'éditeur

Le core.editorparamètre dans mon global .gitconfigest vi(je l'ai également changé vimen un mouvement désespérément désespéré). J'ai essayé d'utiliser mate, mais cela n'a même pas ouvert la liste initiale correctement, je l'ai donc modifiée.

J'utilise la v1.7.3 et je serais heureux de recevoir des suggestions.

Hier n'était qu'un de ces jours. Sur une alouette, j'ai décidé de définir le chemin complet vers vi (par exemple /usr/bin/vi) plutôt que juste l'exécutable. Maintenant, tout fonctionne. Je dois admettre que je ne l'obtiens pas car il viest parfaitement exécutable seul (ma $EDITORvariable env est également définie sur vi), mais cela fonctionne et mon karma technique n'a pas été si bon ces derniers temps, alors peut-être que je ne devrais tout simplement pas remettre en question les divinités vont ...

La commande suivante

git config --global core.editor /usr/bin/vim

le corrige.

[Éditer]

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 ici jusqu'à présent, pour moi, l'utilisation du chemin absolu vers vi et la core.editorconfiguration de git config n'étaient pas suffisantes pour résoudre le problème. (Ceux-ci étaient déjà en place.)

Dans ma situation, le problème a été résolu en ajoutant l' -findicateur à la commande vi:

git config --global core.editor '/usr/bin/vi -f'

Une fois que cette -foption est en place, je peux utiliser git rebase -i, et quand je sauvegarde et quitte la liste de validation, le rebase se déroule comme il se doit au lieu de donner l'erreur "Impossible d'exécuter l'éditeur".

La page de manuel de vim indique en ce qui concerne l'option -f,

Pour la version GUI, Vim ne se séparera pas 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 la fin de la session d'édition (par exemple, courrier).

Eh bien, je n'utilise pas une version graphique que je connais. Je cours gitsur la ligne de commande bash dans une fenêtre de terminal sur masOS Sierra 10.12.6. Mais comme git rebase -iattend la fin de la session d'édition, je suppose que c'est pourquoi l' -foption est nécessaire ici. Peut-être que vim (sans -f) essaie de bifurquer / se détacher du shell pour une raison que je n'ai pas été en mesure de 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"):

• vi
• vim

Mais ceux-ci m'ont donné le code de sortie 0 ("succès"):

• /usr/bin/vi
• /usr/bin/vim
• vi -u NONE
• vim -u NONE

J'ai pu le retracer jusqu'au plugin spécifique en désactivant ~/.vimrcet en les ~/.vimrenommant et en les 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 l'a corrigé. Suivi du débogage de mon .vimrc. Ceci est très similaire à l'expérience d'ignu.

Si vous vouliez pour une raison quelconque utiliser sublime, vous pouvez faire quelque chose comme ce qui suit dans votre fichier de configuration globale:

 git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl"

Il m'a juste fallu un certain temps pour retrouver mon problème dans l'un de mes plugins.

(plus précisément, c'était https://github.com/ervandew/supertab )

Je suppose que c'est l'inconvénient de mettre à jour automatiquement tous mes plugins.

Alors meilleur conseil, désactivez la moitié de votre vimrc et de vos plugins. Si cela n'aide pas, le problème vient de votre moitié.

Une autre option consiste à utiliser l' nanoéditeur.

$ whereis nano
$ git config --global core.editor path/to/nano

Le corrige.

J'essayais d'écraser les commits comme indiqué ici https://www.youtube.com/watch?v=V5KrD7CmO4o . Mon éditeur git (notepad ++) s'est ouvert lors de l'étape de rebasage. Mais, à l'étape de modification du message de validation, j'ai vu le problème "Impossible d'exécuter l'éditeur". Cela est probablement arrivé parce que les paramètres de l'éditeur git étaient incorrects et aussi parce que j'ai installé notepad ++ dans un emplacement non standard sur mon système Windows. Autrement dit, 'git config core.editor' m'a donné notepad++ -multilnst- nosession.

Pour résoudre le problème, indiquez le chemin complet comme ceci:

git config --global core.editor "'C:\CustomFolder\NPP\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Reportez-vous: https://www.youtube.com/watch?v=YLxdkcT6H4g

Ê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 installé le plugin de sauvegarde qui n'est pris en charge que dans 1.7.3 et pour une raison quelconque / usr / bin / vim a été soudainement rétrogradé à 1.7.2, peut-être à cause d'une mise à jour majeure de XCode. ..

J'ai eu ce problème aussi quand j'avais déjà eu vim ouvert pour un rebase dans un autre terminal. J'avais commencé le rebase, j'étais interrompu, et quand je suis revenu, je l'ai réessayé à partir de zéro dans l'autre terminal, sans me rendre compte que j'étais au milieu du même rebase ailleurs. Le fait de terminer la session de rebase vim dans l'autre terminal a bien fonctionné.

Curieusement, essayer à nouveau a fonctionné pour moi.

Mes variables core.editor et $ EDITOR ne sont pas définies.

Pour moi, en utilisant Windows: fermez le terminal actuel, et ouvrez-en un autre (win + R, tapez 'cmd', puis 'enter'), puis ça marche soudainement.

Solution VS Code:

git config --global core.editor "/Applications/Visual\ Studio\ Code.app/Contents/MacOS/Electron"