Cygwin git fork() erreur sur pull

Le problème de base est que, parfois, quand je ne 

git pull upstream master

- Je obtenir

remote: Counting objects: 172, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 119 (delta 45), reused 95 (delta 21)
      0 [main] git 8660 fork: child -1 - forked process 4520 died unexpectedly, retry 0, exit code -1073741515, errno 11
error: cannot fork() for index-pack: Resource temporarily unavailable
fatal: fetch-pack: unable to fork off index-pack

Le code de sortie est la même à chaque fois, le nombre d'objets varie comme doe le processus de numéros de cours. Je suis en cours d'exécution avec l'authentification par clé publique contre github via ssh sur Windows 7. Il arrive avec et sans ssh-agent. J'ai eu ce problème depuis plusieurs mois maintenant, et de travailler autour de lui par le passage à Git Bash (MingW32), lorsqu'elle est soulevée, (ce qui est presque à chaque fois avec des référentiels et, occasionnellement ou jamais avec les autres). Cependant je préfère généralement l'environnement Cygwin et ont la plupart des trucs de ma configuration, c'est donc un glisser quand je suis obligé de le faire.

Il y a un moment j'ai vu ce post http://cygwin.com/ml/cygwin/2012-03/msg00025.html et après la lecture, il espère que la prochaine fois que j'ai mis à jour Cygwin qui fixent permettrait de résoudre mon problème aussi. Il n'a pas, mais je n'étais pas sûr si le correctif a été publié, mais j'ai de nouveau mis à jour aujourd'hui et que ça se passe.

J'ai remarqué une pléthore d'e-mails au sujet des erreurs relatives à fork() pour Cygwin git sur le web, mais pas pour les tirer, et donc ma question est, personne n'a jamais vu cela sur traction avant, ce qui les provoque? est-il possible de les prévenir (en dehors de l'application de correctifs git ou cygwin ou à l'aide de quelques autres de la mise en œuvre sûr 🙂 ).

Curieusement j'ai vu exactement à aucun des erreurs pour lesquelles je peux trouver des Cygwin/git mails sur le web.

  • Même problème. J'ai aussi remarqué qu'il semble de pop-up à chaque fois que je fais un git pull à l'encontre d'un référentiel qui a un grand nombre de changements. ---Windows7+Cygwin+SSH contre un privé repo git
  • Pour ce que ça vaut, je suis l'obtention de ce avec un script Bash qui fait assez simple des opérations sur les fichiers texte et génère un fichier CSV. Il ne fait aucun appels externes autres que les bc (la fête de la calculatrice). Je suis en Win7+Cygwin, tourne en local (pas d'accès SSH)
  • Cela peut également aider certaines personnes (même si je n'ai pas essayé): superuser.com/questions/335907/cygwin-x-beginner-trouble
InformationsquelleAutor Gus | 2012-08-20
  1. 25

    OK, je suppose que je devrais partager. J'ai le même problème, mais j'ai une solution de contournement. Le problème semble être de la longueur du CHEMIN. Si je fais un git pull, je reçois la fourche à l'échec:

    $ git pull*texte en gras* 
2 [principal] git 7384 fourche de l'enfant: -1 - fourches processus 7420 est décédé de façon inattendue, réessayer 0, code de sortie -1073741515, errno 11 
erreur: impossible de fork() pour rev-liste: Ressource temporairement non disponible 
erreur: impossible d'exécuter git rev-list' 
distance: Comptage d'objets: 728, c'est fait. 
distance: la Compression des objets: 100% (456/456), c'est fait. 
907550 [principal] git 7384 fourche de l'enfant: -1 - fourches processus 7436 est décédé de façon inattendue, réessayer 0, code de sortie -1073741515, errno 11 
erreur: impossible de fork() pour l'indice-pack: Ressource temporairement non disponible 
fatal: fetch-pack: impossible de bifurquer index-pack

    Cependant, si j'ai mis le CHEMIN d'accès à quelque chose de vraiment petit avant d'exécuter git, il travaille:

    $ PATH=/usr/bin git pull 
distance: Comptage d'objets: 728, c'est fait. 
distance: la Compression des objets: 100% (456/456), c'est fait. 
distance: Total 464 (delta 337), réutilisé 9 (delta 6) 
La réception des objets: 100% (464/464), 153.36 KiB, c'est fait. 
La résolution des deltas: 100% (337/337), complété avec 107 objets locaux. 
À partir de git://cmake.org/cmake

    Je serais intéressé si cela fonctionne pour vous?

    • Malheureusement, je ne peux plus tester cela, comme je l'ai déplacé sur de l'emploi où j'ai été confronté à ce problème.
    • merci beaucoup..j'ai eu du mal à faire ce travail depuis quelques jours..essayé avec rebaseall aussi mais ta solution a fonctionné pour moi...
    • Au lieu de cela, de l'aide de l'alias git suffit d'utiliser le chemin d'accès complet /usr/bin/git.
    • J'ai essayé d'aborder cette question sur le cygwin liste de diffusion, mais pas trouvé preneur sur l'aide jusqu'à présent. Heureux d'entendre que je ne suis pas le seul avec ce problème... Rubens, pour moi, si j'utilise /usr/bin/git, il se bloque toujours.
    • Ce fixe! Merci beaucoup pour me sauver un tas de temps.
    • Ok basée sur le fait que plusieurs personnes dire que cela a fonctionné pour eux, je vais à la remise d'une coche.
    • Mec, j'ai été me frappant la tête contre le mur avec ce pour un an au moins, c'est la première chose que j'ai lu qui aide réellement. Je ne peux pas vous remercier assez. Mettre un bouton Paypal là 🙂
    • J'ai enfin vu cette solution dans l'action. Un de mes clients a eu le problème et je lui ai donné la solution 🙂
    • Ci-dessous la réponse à rebaseall est une BIEN meilleure réponse, et explique entièrement le problème (y compris le pourquoi de ce hack permet de résoudre le problème immédiat).
    • En fait les problèmes, il est PAS la longueur du chemin lui-même, mais plutôt la position de gits l'entrée de ce chemin. Avoir un très long chemin, qui fonctionne bien, lorsque vous assurez-vous que votre git entrée dans la variable path est à l'intérieur de la première 2048 caractères de la voie après tous les raccourcis dans le chemin obtenu complètement développés. Il a travaillé pour moi sans raccourcissement mon chemin après le déplacement de git plus sur le devant de la voie. Encore upvoting. Je n'aurait jamais pensé que le CHEMIN peut être question en l'absence de cette réponse.

    InformationsquelleAutor Bill Hoffman
  2. 35

    Ce point est abordé ici: http://cygwin.wikia.com/wiki/Rebaseall

    En bref, fermez toutes les fenêtres et exécuter ceci:

    C:\cygwin\bin\dash.exe -c '/usr/bin/rebaseall -v'

    Cela résout toutes les questions liées à la fourche. J'ai eu des problèmes avec la fourche aspell de emacs ainsi que git.

    • Aussi, la fermeture de toutes les Cygwin processus peut être une douleur, mais il est nécessaire pour que cela fonctionne. Autre outil que l'additif est qu'il ne serait pas exécuté à partir d'une fenêtre d'invite de commande pour moi, mais de la commande "Exécuter" dialogue il a fait un travail très bien.
    • Ne fonctionne pas pour moi. J'ai babun (1.2.0) car mon cygwin (1.7.35) de l'installation. Le fixer avec le CHEMIN de la manipulation a bien fonctionné
    • J'ai eu exactement le même problème et cette réponse résolu mon problème!
    InformationsquelleAutor Martin Thomson
  3. 4

    J'ai également fait face à un même problème et redémarrez le système résolu.

    • J'ai eu le même problème avec babun à l'aide de windows 10 et de redémarrer résolu ici aussi.
    • Même: babun & Windows 10. Rebaseall n'a pas aider, mais un redémarrage a fait le tour.
    InformationsquelleAutor RootCode
  4. 2

    - Je obtenir que peu de temps a passé, mais j'ai trouvé cela à la recherche de mon propre problème similaire, à l'aide de la cygwin plate-forme construite dans le MobaXterm app. Tirait mes inexistant cheveux à essayer de le comprendre, en fin de compte, il a été fixé par un simple redémarrage.

    Je double vérifié que cela a fonctionné avec un deuxième Windows 10 de la machine, une nouvelle installation de MobaXterm + git applications, et une tentative de tirer à partir d'un dépôt github. Même message d'erreur: "erreur: impossible de fork() pour l'indice-pack: Ressource temporairement non disponible" a été réalisé, et un simple redémarrage de l'ordinateur fixe.

    • J'ai dû réinstaller MobaXterm, puis réinstallez-le. Le redémarrage a pas assez sur son propre, la réinstallation n'était pas assez sur son propre. Mais avec leurs pouvoirs combinés! Merci PNJ!
    InformationsquelleAutor N Phillip Cole NPC
  5. -3

    Au lieu de définir la variable de CHEMIN d'accès ou l'utilisation de git chemin d'accès complet (une fois), cela devrait fonctionner ainsi:

    git=`which git`
git pull

    Cela va affecter git à son chemin d'accès complet pour les appels consécutifs. Maintenant, si git est utilisé dans un autre programme(comme le font), il sera en mesure de.

    • Ce que vous avez écrit ne sera pas faire beaucoup de chose, vous n'êtes pas à l'aide de la variable que vous avez définie. Et c'est un peu inutile de toute façon étant donné que vous devez spécifier le chemin d'accès au moins une fois, ou sont en VOIE d'abord.
    • La variable est utilisée...ne sais pas de quoi vous parlez. Après sa mise en, echo $git confirme ce. De toute façon, il a résolu le problème pour moi, donc...imagine que je suis le seul.
    • Tant pis, je vois ce que vous dites. Il n'résoudre le problème pour moi, même si...je ne sais pas pourquoi, mais il le fait.
    • Regarde le code que vous avez posté près. git pull et $git pull sont deux choses complètement différentes déclarations (potentiellement).
    • Oui, je vois que maintenant (il est tard). Mais comme je l'ai dit, ça marche...l'enfer peut-être mettre AUCUNE variable n'a le truc?? Je vais l'essayer et d'en faire rapport à la prochaine fois que ça m'arrive.
    • Ok, je viens de réfuter que ma réponse NE fait PAS de travail...je n'ai même mentionné 🙁 Merci pour l'ouverture de mes yeux Mat

    InformationsquelleAutor codesnip3r