git-lfsは大容量のファイルを扱うもので多量のファイルを扱うものではない

git-lfsの説明については参考URLをどうぞ

　参考

• https://git-lfs.github.com/
• http://qiita.com/kiida/items/0d51c43ac73f14f09f5a

さてgit-lfsがver1.0になってgithub.comでもサイズ上限を気にしないでもいい最高の未来が訪れたぞやったー！とか思ったのですがぬか喜びでした。

結論から言うと、画像が沢山あって1GB以上あるリポジトリをgithub.comに置こうと思ったのにgit-lfsで扱ったら１ファイルあたりのオーバーヘッドがでかすぎて死んだ。

cloneがとにかく遅い

試しにリポジトリをひとつcloneしてみる。上のリポジトリは100KB程度の異なる画像を100枚コミットしてある。

git-lfsがインストール済みの状態でcloneすると自分の環境では9分ほどかかった。
というのも通常のgitリポジトリクローンの後にlfsとして登録されたファイルのfetchが始まる。直列なうえにどうやら北米のサーバーに取りに行ってるらしい。

回避策・git-lfsの処理タイミングを遅らせる

一応この遅いcloneを回避する事はできて、clone時のgit-lfsの処理を飛ばして後からfetchすると非常に高速に出来る

$ GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/hoshina85/lfstest2.git

$ cd lfstest2
$ git lfs fetch
Fetching master
Git LFS: (100 of 100 files) 9.69 MB / 10.47 MB
real    0m6.230s
user    0m0.714s
sys     0m0.425s

lfs fetchはバッチで処理してくれるらしい。それでも100ファイルで6秒かかってるので千や万のオーダーになったらお察しである。

回避策・github enterpriseを使う

GHEで国内にサーバーをおくとなんぼか速いという話を聞いた。使ってないので試してはいない。ただしGHEはリポジトリサイズ上限がないのでlfs使わずとも普通にコミットすればいい。100MB以上のファイルをコミットできるという利点はある。

つまり

git-lfsはPSDとかmpegとか単体でめっちゃでかいファイルを扱うためのもので多量の小さなリソースが詰まったリポジトリで使うようなものではない。今のところ。