magit-push si blocca su Windows


10

Sto usando GNU Emacs su Windows e non sono in grado di utilizzare magit-pushper inviare le mie modifiche locali a un repository remoto. Ciò accade con i repository remoti indipendentemente dal fatto che siano accessibili con SSH o HTTPS. Cosa devo fare per far magit-pushfunzionare Windows senza problemi (o almeno quasi) come sui miei computer Linux?

Tutto ciò che vedo nel *Messages*buffer è

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

Lo stesso mostra nel *magit-process*buffer, più o meno. Niente di più utile. Sono in grado di eseguire push dalla riga di comando, ma richiede la password della mia chiave ssh. Potrebbe essere questo il problema? Ho provato a caricare la chiave con Pageant (l'agente chiave di PuTTY), ma non sembrava fare la differenza.

Se è utile, ho installato Cygwin e sarei felice con una soluzione che prevedeva l'obbligo per Emacs di utilizzare gli eseguibili di Cygwin.

Risposte:


6

La wiki di Magit ora presenta una pagina sui vari modi in cui si può spingere da Magit quando si utilizza MS Windows. Acquista anche il nuovo ssh-agencypacchetto. Sia la pagina wiki che il pacchetto sono stati scritti da @npostavs.

Nota inoltre che non è praticamente mai colpa di Magit se non puoi spingere. Di solito è un problema di configurazione (anche se puoi spingere dalla shell ma non quando usi Magit).


6

Di solito, il problema è che Emacs non può accedere alla richiesta di password di git su Windows. Pertanto, sembra "bloccarsi" in modalità push, dove sta davvero aspettando la tua password. Puoi aggirare questo problema usando una chiave ssh invece di un nome utente / password nel tuo repository git, e facendo il primo push manualmente nella shell (git ricorderà la tua password ssh dopo il primo push).


1
La shell bash Git non sembra ricordare la mia password SSH, quindi più push stanno vedendo la stessa cosa.
Ryan,

3

Se non lo hai già fatto, ti consiglio di utilizzare SSH anziché HTTP come molti mi hanno consigliato durante le mie indagini su questo. Detto questo, sono stato in grado di risolvere questo problema utilizzando le FAQ seguenti:

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

Il componente mancante (dallo script Git Bash .bashrc di Github) è che non gestisce l'avvio di ssh-agent per interfacce come la riga di comando di Windows o emacs. Seguendo i passaggi precedenti avvia ssh-agent all'avvio di emacs. Nota, dovrai avviare Git Bash e inserire la tua passphrase SSH all'avvio / riavvio del computer.


2

Anch'io ho sperimentato questo comportamento per un po 'e fino ad oggi non sono riuscito a cercare davvero di risolverlo. L'ho fatto inserendo quanto segue nel mio file init:

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

Ho anche provato questo aprendo un Emacs pulito ( emacs -Q), caricando magite valutando quella linea, e ha funzionato.

Funziona con Pageant, quindi non c'è bisogno di scherzare ssh-agent.


1
Per me questa è stata la soluzione migliore per qualcuno che ha installato git da riga di comando e gli eseguibili relativi a PuTTY come il concorso.
Tom Purl,

1

Se hai già installato Cygwin, puoi utilizzare il portachiavi e l' ambiente portachiavi per gestire le tue chiavi.

Usa quindi la shell di tua scelta per avviare il portachiavi

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

per garantire che le chiavi siano caricate in Emacs.


Hmmm. Ci ho provato e nulla è cambiato davvero. Il magit-pushcomando è stato sospeso come sempre.
Ryan,

1

Non ho mai capito come risolvere questo problema con MSYS Git ed Emacs, ma ecco una soluzione semplice.

Aggiungi Git Credential Winstore al tuo $ PATH. Git-Credential-Winstore utilizzerà il portachiavi di Windows per gestire le password per te e Magit spingerà felicemente verso repository remoti.

Nel tuo .gitconfigfile, imposta quanto segue:

[credential]
        helper = "winstore"

Questo perché Documenti sulle credenziali di Git affermano che "se il nome dell'helper non è un percorso assoluto, allora la stringa git credential- viene anteposta". Preferisco questo approccio.

In alternativa, puoi semplicemente eseguire git-credential-winstore.exe e si installerà automaticamente nella tua cartella AppData e riempirà il tuo .gitconfigfile con un percorso hardcoded alla sua posizione. Dopo averlo eseguito, .gitconfigapparirai così:

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

Il punto esclamativo indica a Git di trattare la stringa come un percorso assoluto.


0

Come ha sottolineato @bastibe, Magit probabilmente sta aspettando l'immissione di una password e si blocca solo lì ...

Ricordo il seguente lavoro quando sono stato costretto a usare Windows :-). Non ricordo il nome esatto del comando, anche assicurarsi che exec-pathcontenga c:/Program Files (x86)/Git/bin/.

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

0

Ho eseguito runemacs.exe dalla shell git. Ora la spinta git di magit funziona.


1
Ciò non sembra in alcun modo correlarsi alla domanda. Se intendevi rispondere alla domanda, modifica la tua risposta che spiega come la corsa runemacssia in qualche modo correlata a Magit.
Gilles 'SO- smetti di essere malvagio' il

simpatico. vengo contrassegnato per la cancellazione prima ancora di avere la possibilità di spiegare meglio? è una risposta (soluzione) al problema.
Majid alDosari,

1
Non credo che la risposta meriti di essere sottoposta a downgrade. Ma potrebbe essere meglio spiegare il motivo per cui ha funzionato (se in esecuzione dalla shell Git su Windows, alcune variabili di ambiente verranno inizializzate in modo diverso in Emacs, questo farà sì che Magit sia in grado di interagire con Git nel modo in cui comprende). Forse il modo in cui OP ha cercato di eseguire i comandi Magit ha interagito con Git in un modo che Magit non si aspettava.
wvxvw,

1
Questa è una risposta L'utente potrebbe non sapere perché ha fatto la differenza, ma stanno dicendo cosa ha funzionato nel loro caso.
Malabarba,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.