magit-push se cuelga en Windows


10

Estoy usando GNU Emacs en Windows, y no puedo usarlo magit-pushpara enviar mis cambios locales a un repositorio remoto. Esto sucede con los repositorios remotos, independientemente de si se accede a ellos con SSH o HTTPS. ¿Qué debo hacer para que el magit-pushtrabajo en Windows funcione tan bien (o al menos casi) como en mis máquinas Linux?

Todo lo que veo en el *Messages*búfer es

Running c:/Program Files (x86)/Git/bin/git.exe push -v origin master:refs/heads/master

Lo mismo se muestra en el *magit-process*búfer, más o menos. Nada mas util. Puedo acceder a git push desde la línea de comandos, pero me pide la contraseña de mi clave ssh. ¿Podría ser ese el problema? Intenté cargar la clave con Pageant (agente clave de PuTTY), pero eso no pareció marcar la diferencia.

Si es útil, tengo instalado Cygwin, y estaría contento con una solución que involucrara forzar a Emacs a usar los ejecutables de Cygwin.

Respuestas:


6

El wiki de Magit ahora presenta una página sobre las diversas formas en que uno puede empujar desde Magit cuando usa MS Windows. También verifique el nuevo ssh-agencypaquete. Tanto la página wiki como el paquete fueron escritos por @npostavs.

También tenga en cuenta que prácticamente nunca es culpa de Magit si no puede empujar. Por lo general, es un problema de configuración (incluso si puede empujar desde el shell pero no cuando usa Magit).


6

Por lo general, el problema es que Emacs no puede acceder a la solicitud de contraseña de git en Windows. Por lo tanto, parece que se "cuelga" al presionar, donde realmente está esperando su contraseña. Puede eludir esto utilizando una clave ssh en lugar de un nombre de usuario / contraseña en su repositorio de git, y haciendo la primera inserción manualmente en el shell (git recordará su contraseña ssh después de la primera inserción).


1
El shell Git bash no parece recordar mi contraseña ssh, por lo que más empujones solo están viendo lo mismo.
Ryan

3

Si aún no lo ha hecho, recomendaría usar SSH en lugar de HTTP, ya que muchos me lo recomendaron durante mi investigación de esto. Dicho esto, pude resolver este problema usando las siguientes preguntas frecuentes:

https://github.com/magit/magit/wiki/FAQ#windows-cannot-push-with-ssh-passphrase

El componente que falta (del script Git Bash .bashrc de Github) es que no maneja el inicio de ssh-agent para interfaces como la línea de comandos de Windows o emacs. Seguir los pasos anteriores inicia ssh-agent al iniciar emacs. Tenga en cuenta que deberá iniciar Git Bash e ingresar su frase de contraseña SSH al iniciar / reiniciar su máquina.


2

Yo también he experimentado este comportamiento por un tiempo, y hasta hoy no he podido realmente tratar de arreglarlo. Lo hice colocando lo siguiente en mi archivo init:

(setenv "GIT_SSH" "C:/Path/to/PuTTY/plink.exe")

También probé esto abriendo un Emacs limpio ( emacs -Q), cargando magity evaluando esa línea, y funcionó.

Esto funciona con Pageant, por lo que no hay necesidad de meterse con ssh-agent.


1
Para mí, esta fue la mejor solución para alguien que ha instalado git de línea de comandos y los ejecutables relacionados con PuTTY como el concurso.
Tom Purl

1

Si ya tiene instalado Cygwin, puede usar llavero y entorno de llavero para administrar sus claves.

Use el caparazón de su elección para iniciar el llavero, luego

(require 'keychain-environment)
(keychain-refresh-environment)

para garantizar que las claves se carguen en Emacs.


Hmmm Intenté esto, y nada realmente cambió. El magit-pushcomando colgaba como siempre lo hace.
Ryan

1

Nunca descubrí cómo solucionar esto solo con MSYS Git y Emacs, pero aquí hay una solución transparente.

Agregue Git Credential Winstore a su $ PATH. Git-Credential-Winstore usará el llavero de Windows para administrar sus contraseñas por usted y Magit se trasladará felizmente a repositorios remotos.

En su .gitconfigarchivo, configure lo siguiente:

[credential]
        helper = "winstore"

Esto funciona porque los documentos de credenciales de Git establecen que "si el nombre del ayudante no es una ruta absoluta, entonces la cadena de credenciales de git se antepone". Prefiero este enfoque.

Alternativamente, simplemente puede ejecutar git-credential-winstore.exe y se instalará en su carpeta AppData y completará su .gitconfigarchivo con una ruta codificada a su ubicación. Después de ejecutarlo, .gitconfigse verá así:

[credential]
        helper = !"c:\\Users\Joe\\\AppData\\Roaming\\GitCredStore\\git-credential-winstore.exe"

El signo de exclamación le indica a Git que trate la cadena como una ruta absoluta.


0

Como señaló @bastibe, Magit probablemente esté esperando una entrada de contraseña y simplemente se queda allí ...

Recuerdo el siguiente trabajo cuando me vi obligado a usar Windows :-). No recuerdo el nombre exacto del comando, también asegúrese de que exec-pathcontiene c:/Program Files (x86)/Git/bin/.

(setenv "GIT_ASKPASS" "git-gui--askpass")

0

Ejecuté runemacs.exe desde el shell git. Ahora el empuje git de magit funciona.


1
Esto no parece estar relacionado con la pregunta de ninguna manera. Si runemacstenía la intención de responder la pregunta, edite su respuesta que explique cómo la ejecución está relacionada de alguna manera con magit.
Gilles 'SO- deja de ser malvado'

bonito. me marcan para eliminar antes de que incluso tenga la oportunidad de explicar mejor? Es una respuesta (solución) al problema.
Majid alDosari

1
No creo que la respuesta merezca ser rechazada. Pero puede ser mejor explicar la razón por la que funcionó (si se ejecuta desde el shell de Git en Windows, algunas variables de entorno se inicializarán de manera diferente en Emacs, esto también hará que Magit pueda interactuar con Git de la manera en que lo entiende). Quizás la forma en que OP intentó ejecutar los comandos de Magit interactuó con Git de una manera que Magit no esperaba.
wvxvw

1
Esta es una respuesta Es posible que el usuario no sepa por qué marcó la diferencia, pero está diciendo lo que funcionó en su caso.
Malabarba
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.