Git gc utilisant une mémoire excessive, incapable de terminer

Question

Dernière mise à jour et correctif: La solution ici s'est avéré être une combinaison de deux choses: à l'aide de Windows Git plutôt que Cygwin Git comme Graham Borland a suggéré, et le Git config paramètres pack.threads = 1 et gc.aggressiveWindow = 150.

J'ai un grand dépôt Git local, un git svn clone d'un dépôt SVN avec environ 40 000 commits. J'essaie de l'exécuter, git gc plus de ce référentiel, et nulle part:

$ git gc --auto
Auto packing the repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 25966, done.
Compressing objects: 100% (25249/25249), done.
fatal: Out of memory, malloc failed (tried to allocate 426523986 bytes)
error: failed to run repack

Je suis en cours d'exécution Git 1.7.5.1 à l'intérieur de Cygwin sur un 64-bit dual-core Win7 machine avec 4 go de RAM. L' .git annuaire est actuellement un peu plus de 6,1 GO.

J'ai essayé de courir git gc --aggressive, pour voir si le système plus complet est en mesure de le réparer, mais pas de chance: je reçois un message similaire à celle ci-dessus, avec la même taille tenté malloc, mais une augmentation significative du nombre d'objets (508,485 compté, 493,506 comprimé).

J'ai aussi essayé-comme suggéré par Google-assortiment de twiddles à l' [pack] partie de mon .gitconfig le dossier; le plus d'être complet à partir d' un autre StackOverflow question. Mon .gitconfig a maintenant la suite des lignes, mais la définition de ces semble avoir fait aucune différence:

[pack]
        windowMemory = 16m
        threads = 1
        window = 1
        depth = 1
        deltaCacheSize = 1

Toutes les suggestions sur comment je peux obtenir de l' git de gc mon dépôt?

Edit: Marque Longair suggéré certains plus .gitconfig des modifications de fichiers. Que j'ai fait, de nouvelles lignes ci-dessous. Mais les changements ne fait pas de différence que ce soit.

[core]
        packedGitWindowSize = 1m
        packedGitLimit = 256m
[pack]
        packSizeLimit = 128m

Edit 2: Michael Krelin suggéré d' augmenter le swap/taille de fichier de page (WinXP instructions ici, et c'est pareil pour Win7). J'ai essayé, mais il ne fait aucune différence, et en effet, j'ai seulement augmenté la taille maximale disponible, et il semble que si Windows n'a jamais essayé d'augmenter la taille du fichier de la page c'est à l'aide.

Je suis en train de regarder si cela a été causé par une limite de mémoire à l'intérieur ou imposé Cygwin. Cocher la case "imposé", j'essaie de course Cygwin avec des privilèges d'administrateur. Cocher la case "à l'intérieur" (ce qui est plus probable), je vais avoir un jeu avec Cygwin maximum de paramètres de la mémoire.

Edit 3: Beaucoup si je préfère l'utilisation de Cygwin, il s'avère que le Windows client de Git traite de la question de la mémoire à l'amende juste. Semble que je vais retomber que de temps en temps quand mon référentiel a besoin d'un ordre.

Answer 1

J'ai eu le même problème, j'ai essayé les solutions mentionnées jusqu'à présent sans succès. Mais mes problèmes avec git gc ont commencé après que j'ai ajouté de gros fichiers image au référentiel. J'ai donc créé le fichier .gitattributes et désactivé la compression delta pour ces gros fichiers:

 *.tga -delta
*.psd -delta
 

Ça a marché.

Answer 2

Vous aurez peut-être plus de chance avec un client Windows natif tel que msysGit , plutôt que d'essayer de le faire dans Cygwin.

Answer 3

Parmi les autres options de configuration que vous pouvez essayer de limiter à des valeurs inférieures aux valeurs par défaut, citons:

• pack.packSizeLimit
• core.packedGitWindowSize
• core.packedGitLimit

... qui sont tous documentés dans la documentation git config . Dans chaque cas, il est particulièrement intéressant de vérifier quelles unités sont comprises et avec lesquelles j'ai commis des erreurs par le passé.

Answer 4

La seule chose qui a aidé à éviter cette erreur sur l’hébergement Linux partagé a été d’ajouter

   [pack]
    packSizeLimit = 64m
    threads = 1
 

à

 .gitconfig
 

Le plus important était "threads = 1"

Answer 5

Peut-être qu’ajouter temporairement un fichier d'échange plus volumineux et aller prendre quelques tasses de café ailleurs vous aidera?