Nie udało się uruchomić edytora

Nie często muszę modyfikować wiele komunikatów o zatwierdzeniach, ale zdarzyło się to raz lub dwa razy i nigdy nie pamiętam, żebym to widział. Mam nadzieję, że ktoś inny. Kiedy ja git rebase -i HEAD~7, oczekiwana lista otwiera się w vi dokładnie tak, jak oczekiwano. Zmieniam pickwartości na editodpowiednie, a następnie :wq.

Nie udało się uruchomić edytora

core.editorUstawienie w moim globalny .gitconfigjest vi(ja też zmienić go vimw szalenie desperackim ruchu). Próbowałem użyć mate, ale to nawet nie otworzyło poprawnie początkowej listy, więc zmieniłem ją z powrotem.

Używam wersji 1.7.3 i mile widziane są wszelkie sugestie.

Wczoraj był tylko jeden z tych dni. Na próżno zdecydowałem się ustawić pełną ścieżkę do vi (np. /usr/bin/vi), A nie tylko plik wykonywalny. Teraz wszystko działa. Muszę przyznać, że nie rozumiem, ponieważ sam w sobie vijest doskonale wykonywalny (moja $EDITORzmienna env jest również ustawiona na vi), ale działa, a moja techniczna karma ostatnio nie była tak duża, więc może po prostu nie powinienem kwestionować bóstwa będą ...

Następujące polecenie

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

naprawia to.

[edytować]

Teraz widzę, że ktoś już to opublikował w komentarzach. Mam nadzieję, że jest to nadal pomocne dla niektórych niewidomych ludzi, takich jak ja.

W przeciwieństwie do innych odpowiedzi tutaj do tej pory, dla mnie użycie bezwzględnej ścieżki do vi i ustawienie core.editorkonfiguracji git nie było wystarczające do rozwiązania problemu. (Te były już na miejscu.)

W mojej sytuacji problem został rozwiązany poprzez dodanie -fflagi do polecenia vi:

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

Gdy ta -fopcja jest już dostępna, mogę użyć git rebase -i, a kiedy zapisuję i zamykam listę zmian, rebase postępuje tak, jak powinno, zamiast wyświetlać błąd „nie można uruchomić edytora”.

Strona podręcznika vim mówi o opcji -f,

W przypadku wersji z GUI, Vim nie będzie forkował i nie odłączał się od powłoki, w której został uruchomiony. ... Ta opcja powinna być używana, gdy Vim jest uruchamiany przez program, który będzie czekał na zakończenie sesji edycji (np. Poczta).

Cóż, nie używam wersji GUI, o której wiem. Uruchamiam gitw wierszu poleceń bash w oknie terminala na masOS Sierra 10.12.6. Ale ponieważ git rebase -iczeka na zakończenie sesji edycji, przypuszczam, że dlatego -fopcja jest tutaj konieczna. Może vim (bez -f) próbuje rozwidlić / odłączyć się od powłoki z jakiegoś powodu, którego nie byłem w stanie zrozumieć.

Miałem ten problem i był on spowodowany przez jakąś część wtyczki vcscommand dla vima. Uruchomienie vima z którymkolwiek z tych poleceń spowodowało kod zakończenia 1 („błąd”):

• vi
• vim

Ale te dały mi kod zakończenia 0 („sukces”):

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

Udało mi się prześledzić to z powrotem do konkretnej wtyczki, wyłączając ~/.vimrci pliki ~/.vim, zmieniając ich nazwę i uruchamiając, vi -c q ; echo $?aby szybko uruchomić vim i wydrukować kod zakończenia.

Dla mnie był to problem z moim .vimrc. Tymczasowa zmiana nazwy tego pliku naprawiła problem. Następnie debugowanie pliku .vimrc. Jest to bardzo podobne do doświadczenia ignu.

Jeśli z jakiegoś powodu chcesz użyć sublime, możesz zrobić coś takiego w swoim globalnym pliku konfiguracyjnym:

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

Zajęło mi trochę czasu, zanim wyśledziłem mój problem w jednej z moich wtyczek.

(konkretnie było to https://github.com/ervandew/supertab )

Myślę, że to wada automatycznego aktualizowania wszystkich moich wtyczek.

Więc najlepsza rada, wyłącz połowę swojego vimrc i wtyczek. Jeśli to nie pomoże, problem jest z twoją drugą połową.

Inną opcją jest użycie nanoedytora.

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

Naprawia to.

Próbowałem zmiażdżyć commity, jak pokazano tutaj https://www.youtube.com/watch?v=V5KrD7CmO4o . Mój edytor git (notepad ++) otworzył się na etapie ponownego bazowania. Ale w kroku komunikatu o zmianie zmiany zobaczyłem problem „Nie można uruchomić edytora”. Prawdopodobnie stało się tak, ponieważ ustawienia edytora git były złe, a także dlatego, że zainstalowałem Notatnik ++ w niestandardowej lokalizacji w moim systemie Windows. To znaczy, dał mi „git config core.editor” notepad++ -multilnst- nosession.

Aby rozwiązać problem, podaj pełną ścieżkę w następujący sposób:

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

Zobacz: https://www.youtube.com/watch?v=YLxdkcT6H4g

Czy jesteś pewien, że / usr / bin / vim był w wersji 1.7.3? Miałem ten sam problem, ponieważ miałem zainstalowaną wtyczkę do tworzenia kopii zapasowych, która jest obsługiwana tylko w wersji 1.7.3 iz jakiegoś powodu / usr / bin / vim został nagle zdegradowany do wersji 1.7.2, być może z powodu dużej aktualizacji XCode. ..

Miałem również ten problem, gdy miałem już otwarty vim na rebase w innym terminalu. Zacząłem od nowa, zostałem przerwany, a kiedy wróciłem, spróbowałem ponownie od zera na drugim terminalu, nie zdając sobie sprawy, że jestem w trakcie tego samego odradzania gdzie indziej. Samo zakończenie sesji rebase vima na drugim terminalu działało dobrze.

Co dziwne, po prostu próbowanie tego ponownie zadziałało.

Moje zmienne core.editor i $ EDITOR nie są ustawione.

U mnie, używając windows: zamknij bieżący terminal i otwórz inny (win + R, wpisz 'cmd', a następnie 'enter'), a potem nagle działa.

Rozwiązanie VS Code:

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