Git Push se bloque lorsque vous poussez vers Github?
Git Push se bloque à chaque fois que j'essaie de Push to github. J'utilise Cygwin et Windows 7. Les fonctions Git permettent de suivre localement les branches, de fournir l'état, de configurer les noms d'utilisateur.nom et utilisateur.email globaux et d'autoriser les validations.
Je suis encore nouveau et en apprentissage.
Je saisis git Push, git Push Origin master ou git Push -u Origin master et je n’obtiens rien mais une ligne vierge qui m’oblige à ctl-c pour récupérer l’invite.
ssh-keygen -t rsa -C "[email protected]" me demande un nom de fichier et se bloque
git Push heroku master se bloque
$ git status renvoie On branch master nothing to commit, working directory clean
$ git pull renvoie Already up to date
$ git remote -v renvoie:
heroku [email protected]:myherokusite.git (fetch)
heroku [email protected]:myherokusite.git (Push) Origin
https://github.com/gitusername/appname.git (fetch) Origin
https://github.com/gitusername/appname.git (Push)
or the correct ssh remote settings are returned when trying this with ssh
Mise à jour: L'utilisation de l'URL SSH [email protected]:gitusername/gitrepo.git se bloque également
git remote set-url Origin https://github.com/gitusername/appname.git est correct
Mise à jour: Je vois les processus git en cours d'exécution dans le gestionnaire de tâches Windows pendant le blocage.
J'ai essayé:
Utilisation de différents emplacements de connexion Internet
basculer entre https et ssh et il se bloque
Git désinstallé. Réinstallé à partir de: https://code.google.com/p/msysgit/downloads/list
Git désinstallé. Installé le git de Cygwin
Git désinstallé. Installé Github pour Windows GUI app et il était capable de pousser. Mais cette application a des fonctionnalités limitées, me force hors de ma fenêtre Cygwin vers une autre application qui me force ensuite dans une invite de commande Windows pour obtenir une fonctionnalité complète que je pensais avoir échappée à l'aide de Cygwin.
J'ai passé de nombreuses heures à essayer de résoudre ce problème, cela fonctionnait sans problème auparavant, merci.
UPDATE 4/2014: J'ai reconstruit toute ma machine sous Windows 7, Cygwin, etc. et tout fonctionne correctement
git config --global core.askpass "git-gui--askpass"
Cela a fonctionné pour moi. Cela peut prendre de 3 à 5 secondes pour que l’invite apparaisse, il vous suffit de saisir vos informations de connexion et vous pourrez continuer.
Essayez GIT_CURL_VERBOSE = 1 Git Push ... Cela peut arriver en raison du paramétrage du proxy. Git tentera d'atteindre github.com via un serveur proxy et le proxy ne répond pas. Avec GIT_CURL_VERBOSE = 1 affichera l'adresse IP et quelques informations. vous pouvez comparer l'adresse IP avec le résultat de la commande "Host www.github.com". si elles sont différentes, vous pouvez créer https_proxy = "" et réessayer.
Essayez de créer un script tel que ~/sshv.sh qui vous montrera ce que ssh peut faire:
#!/bin/bash
ssh -vvv "$@"
Autoriser l'exécution du fichier ~/sshv.sh pour le propriétaire du fichier:
chmod u+x ~/sshv.sh
Puis appelez votre git Push avec:
GIT_SSH=~/sshv.sh git Push ...
Dans mon cas, cela m'a aidé à comprendre que j'utilisais des connexions partagées ssh qui devaient être fermées. J'ai donc tué ces processus ssh et cela a commencé à fonctionner.
J'ai eu le même problème avec absolument les mêmes symptômes… J'étais sur le point de reconstruire tout mon système dans mon désespoir)).
J'étais même si naïf d'essayer git config --global core.askpass "git-gui--askpass" comme certaines personnes le suggèrent, mais cela n'a pas fonctionné… git Push était toujours gelé…
Mais ensuite j'ai compris qu'il y avait une erreur avec mon agent SSH. J'ai donc redémarré ssh-agent et… PROFIT
Conclusion: vérifiez toujours votre agent SSH et votre serveur SSHD lorsque vous rencontrez des problèmes de connexion SSH… Je suis presque certain que c'était votre problème (et c'est pourquoi cela a fonctionné après la réinstallation de votre système).
Cela vaut la peine de vérifier si vous utilisez le git cygwin ou un git externe (c'est-à-dire github).
Si whereis git retourne simplement /cygdrive/c/Program Files (x86)/Git/cmd/git.exe ou similaire, de manière à installer le paquet cygwin git, le problème est résolu pour moi.
Essayez ce qui suit.
git config --global core.askpass "git-gui - askpass"
Cela demandera les informations d'identification, puis "Push" réussira si les informations d'identification sont correctes.
Je pensais que mon écran de fenêtres Git avait été frappé, mais en réalité, une invite d’ouverture de session se trouvait derrière. Vérifiez-la et entrez vos informations d’identité et c’est tout.
J'ai eu le même problème. Cessez de vous inquiéter et de chercher d’innombrables solutions compliquées, Retirez simplement Git et réinstallez-le.
Sudo apt-get purge git
Sudo apt-get autoremove
Sudo apt-get install git
C'est tout. Ça devrait marcher maintenant
Cela s'est produit lorsque l'espace disque de mon ordinateur était saturé. Supprimez certains fichiers et videz la corbeille pour la réparer.
Dans mon cas, le problème était qu'un processus avait verrouillé mon accès au trousseau ...
Forcez la fermeture de toutes les autres applications pour vous assurer que l'accès au trousseau n'est pas verrouillé sur votre Mac.
Je voulais simplement dire que ce problème se pose sur mes instances AWS EC2. J'essayais de transmettre à partir de mon instance EC2 elle-même, lorsque je l'ai configurée pour autoriser uniquement le trafic entrant à partir de l'équilibreur de charge. J'ai changé la règle pour autoriser HTTP à entrer de partout, mais cela ne résout toujours pas le problème. J'ai ensuite réalisé que c'était parce que mes groupes de sécurité sont configurés pour ne pas autoriser le trafic sortant de mes instances EC2 via HTTPS. Je ne disposais pas de l'autorisation de trafic entrant HTTPS pour le faire fonctionner, même si le fait que HTTPS soit disponible est probablement une bonne politique.
Par souci d’exhaustivité (parfois, des problèmes de ce genre ne sont pas aussi compliqués qu’ils pourraient paraître):
Avoir un référentiel distant non existant configuré peut également entraîner ce problème - j'ai récemment découvert cette erreur en modifiant accidentellement l'URL de mon origine en githu.com.
J'ai également eu un problème où git se bloque sur la partie "Écriture d'objets" de Windows 7 (à l'aide de msysgit, le client Windows par défaut de git) et c'est le premier hit que j'ai eu dans google, donc je vais aussi poster ma réponse ici.
git config --global core.askpass "git-gui--askpass" n'a pas fonctionné malencontreusement, mais après quelques recherches, j'ai trouvé l'astuce sur Git Push s'arrête sur "Écriture d'objets: 100%" à utiliser git config –global sendpack.sideband false qui fonctionne parfaitement.
Je peux enfin pousser à partir de la ligne de commande à nouveau!
Je me demande si c'est la même chose que moi ...
- Aller dans mastic
- Cliquez sur "Paramètres par défaut" dans les sessions enregistrées. Cliquez sur Charger
- Allez à la connexion -> SSH -> Bugs
- Définissez "Chokes sur les demandes de Winadj" de PuTTY SSH-2 "sur On (au lieu de Auto)
- Retour à la session dans l'arborescence (en haut de la liste)
- Cliquez sur "Paramètres par défaut" dans la zone Sessions sauvegardées. Cliquez sur Enregistrer.
Ceci (presque mot pour mot) vient de:
Avait le même problème. Étais un peu confus, mais le fait était que j'avais un git init --bare sur root, cela signifie que vous ne pourrez pas faire de Push parce que vous n'avez aucun droit. À la place, créez un nouvel utilisateur ou, dans mon cas, j’ai utilisé Pi User et fait git init --bare, ce qui a fonctionné par la suite.
git config --global http.postBuffer 524288000
Taille maximale en octets de la mémoire tampon utilisée par les transports HTTP intelligents lors de l'envoi de données au système distant. Pour les demandes dépassant cette taille de mémoire tampon, HTTP/1.1 et Transfer-Encoding: chunked permettent d'éviter de créer localement un fichier de pack volumineux. La valeur par défaut est 1 Mio, ce qui suffit pour la plupart des demandes.
J'ai eu deux dépôts, poussant à l'un d'entre eux qui a bien fonctionné. Donc, j'ai comparé leur .git/config. Le non-travailleur avait à la fin:
[http]
sslVerify = false
Celui qui travaillait avait à la place:
[credential]
helper = store
Changer .git/config a résolu le problème.
En général, je me verrai confronté à ce problème lors de l’expulsion d’une grande quantité de fichiers.
Si vous pouvez être patient et laisser les fichiers terminer le téléchargement, vous n'aurez peut-être rien à faire. Bonne chance -