web-dev-qa-db-ja.com

Gitプル致命的：メモリ不足、mallocが失敗しました

https://bitbucket.org/ にレポがあります

数日前、誤って多数の画像ファイルがリポジトリにプッシュされました。その後、ファイルは別のプッシュを介して削除されました。その後、レポは正常に機能しましたが、今日、レポからプルしようとすると：

$ git pull
Password for 'https://[email protected]': 
warning: no common commits
remote: Counting objects: 4635, done.
remote: Compressing objects: 100% (1710/1710), done.
fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes)
fatal: index-pack failed

私はもう試した：
1）git config --global pack.windowMemory 1024m
2）

$ git count-objects -v
count: 9
size: 48
in-pack: 4504
packs: 1
size-pack: 106822
Prune-packable: 0
garbage: 0

運が悪い、次にどのような行動を取るべきかわからない...
レポのサイズは約10〜20mのコードである必要があります。次にどのような行動を取るべきですか？

UPDATE 1
私はこれらのコマンドを実行しました：

$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch public/images/*' HEAD
Rewrite a1c9fb8324a2d261aa745fc176ce2846d7a2bfd7 (288/288)
WARNING: Ref 'refs/heads/master' is unchanged

そして

$ git Push --force --all
Counting objects: 4513, done.
Compressing objects: 100% (1614/1614), done.
Writing objects: 100% (4513/4513), 104.20 MiB | 451 KiB/s, done.
Total 4513 (delta 2678), reused 4500 (delta 2671)
remote: bb/acl: ayermolenko is allowed. accepted payload.
To https://[email protected]/repo.git
 + 203e824...ed003ce demo -> demo (forced update)
 + d59fd1b...a1c9fb8 master -> master (forced update)

プルしてから問題なく動作します：

$ git pull
Already up-to-date.

しかし、リポジトリのクローンを作成しようとすると、

~/www/clone$ git clone [email protected]:repo.git
Cloning into 'clone'...
remote: Counting objects: 5319, done.
remote: Compressing objects: 100% (1971/1971), done.
fatal: Out of memory, malloc failed (tried to allocate 4266852665 bytes)
fatal: index-pack failed

UPDATE 2
残念ながら、すべての大きなファイルが見つかりませんでした。いくつかはまだ残っています。だから私はレポのすべてのログを殺すようにサポートに頼んだ

UPDATE 3
結局、私は古いリポジトリを殺して新しいリポジトリを作成しなければなりませんでした。

gitmemoryclonebitbucketgit-clone
10
Elmor

このリポジトリを使用しているのがあなただけの場合は、「 Gitのコミット履歴から巨大なファイルを削除する方法は？ 」で説明されているgitfilter-branchオプションに従うことができます。 -）」

より簡単なオプションは、「 git-filter-branchで大きなファイルを削除する 」の説明に従って、リポジトリを古いコミットに複製し、強制的にプッシュすることです。

どちらの場合も、共同編集者に自分のローカルリポジトリを公開している新しい状態にリセットするように強制します。繰り返しますが、あなたが唯一の協力者である場合、それは問題ではありません。

4
VonC

私の場合、スワップなしで1GB RAMボックスに大きなリポジトリをプルしようとするのと同じくらい簡単なことでした。

私はこのチュートリアルに従いました https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 サーバー上にスワップスペースを作成して作業しました。

彼らの「より速い」方法：

Sudo fallocate -l 4G /swapfile
Sudo chmod 600 /swapfile
Sudo mkswap /swapfile
Sudo swapon /swapfile

/ etc/fstabに追加することで、これらの変更を永続的にすることができます。

/swapfile   none    swap    sw    0   0

/etc/sysctl.confに追加することをお勧めします。

vm.swappiness=10
vm.vfs_cache_pressure = 50
9
steinkel

大きな画像ファイルがプッシュされた後に削除された場合でも、それらはgit履歴に残ります。

Git履歴から強制的に削除することをお勧めします（それは可能だと思いますが、私にはわからない繊細な手順が必要です）。

または、誤って追加されたファイルの前にリポジトリをプルし、リポジトリにパッチを適用して関連する小さなパッチを作成し、クローンを作成して、マスターgitとして使用します（おそらくダンプ/復元を使用）。

詳細はよくわかりませんが、読んだので可能かもしれません

2
Basile Starynkevitch

最近、リポジトリの1つでこの問題が発生しました。同様のエラーで、リポジトリのどこかに隠された大きなファイルを示唆しています。

Cloning into 'test_framework'...
remote: Counting objects: 11889, done.
remote: Compressing objects: 100% (5991/5991), done.
Receiving objects:  66% (7847/11889), 3.22 MiB | 43 KiB/sremote: fatal: Out of memory, malloc failed     (tried to allocate 893191377 bytes)
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOFs:  66% (7933/11889), 3.24 MiB
fatal: index-pack failed

これを回避するために、私は一時的に大きなスワップドライブ（サーバーが要求していた893191377バイトを超える）を作成しました。 方法2 ここから： http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/

これにより、問題のクローンを作成してから削除することができました（誰かがSQLダンプファイルをチェックインしました）。次を使用できます。

git filter-branch --tree-filter 'rm -rf dumpfile.sql' HEAD

gitリポジトリからファイルを削除します。

0
mbarnettjones