11

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

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

$ git pull
Password for 'https://repo@bitbucket.org': 
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://repo@bitbucket.org/repo.git
 + 203e824...ed003ce demo -> demo (forced update)
 + d59fd1b...a1c9fb8 master -> master (forced update)

プルすると正常に動作します:

$ git pull
Already up-to-date.

しかし、レポを複製しようとすると、

~/www/clone$ git clone git@bitbucket.org: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

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

更新 3
最後に、古いリポジトリを削除して新しいリポジトリを作成する必要がありました。

4

4 に答える 4

10

私の場合、スワップなしで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
于 2016-05-17T18:45:53.653 に答える
4

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

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

いずれの場合も、共同作業者が自分のローカル リポジトリを公開している新しい状態にリセットすることを強制します。繰り返しますが、あなたが唯一の協力者であれば問題ありません。

于 2012-12-26T10:19:10.020 に答える
2

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

それらを git 履歴から強制的に削除することをお勧めします (それは可能だと思いますが、私にはわからない微妙な手順が必要です)。

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

詳細はよくわかりませんが、可能性があると読みました

于 2012-12-26T08:50:49.787 に答える
0

最近、リポジトリの 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

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

これにより、クローンを作成して犯人を削除することができました (誰かが SQL ダンプファイルをチェックインしていました)。以下を使用できます。

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

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

于 2014-07-16T18:48:42.830 に答える