git-lfsの説明については参考URLをどうぞ
#### 参考
さて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とか単体でめっちゃでかいファイルを扱うためのもので多量の小さなリソースが詰まったリポジトリで使うようなものではない。今のところ。