Gitの巨大ファイル管理、未来はGitそのものだった！？

LFSのダメなところは他にもあるんだ。リポジトリを移行すると、LFSオブジェクトがない過去のコミットにまで.gitattributesが追加されちゃうんだよ。例えばCコミットでラージファイルを追加しても、AやBコミットまでLFS参照が入っちゃうってこと。

そんなはずないだろ。前のコミットにファイルが追加されるなんてこと、あるわけないじゃん。ハッシュが変わっちゃうから、色々なものがぶっ壊れちゃうぞ！

Git LFSってさ、SSHだと動かなかったんだよね。SSL証明書が必要で、GitHubもそれがセルフホストする人にはハードルだって分かってたみたい。GitLabはSSH対応のパッチを当てた気がするけど。

git lfs migrate はコミットを書き換えちゃうから、ハッシュは変わるんだよ。これは公式ドキュメントにも書いてある。普通は新しいコミットだけが対象だけど、俺はリポジトリ全体をLFS化したかったから、過去のコミットまで.gitattributesが汚染されてガッカリしたよ。詳しくはここを見てくれ！
https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.md

もしアーキテクチャがどうでもよくて、デフォルトでオンにするだけなら、Git LFSでもとっくにできてたはずだろ。

ドキュメントの2パラグラフ目にこう書いてあるぞ、「git lfs migrate はデフォルトで現在チェックアウト中のブランチと、リモートにないコミットで追加されたファイルだけを操作する」って。もしかしてリモートの設定が間違ってたんじゃないの？

Let’s Encryptはさ、Git LFSが始まる3年前にローンチしてるんだぜ。

「Gitはそういうツールじゃない」って言ってるけど、それはGitがラージファイルの追跡がまだ得意じゃないからであって、Gitの根本的な特性じゃないだろ。改善できるはずだよ。あと、「GIT」じゃなくて「Git」ね。

バージョン管理システムはプロジェクト管理のツールで、ソースコード専用じゃないんだ。プロジェクトを複数のストレージに分けるのは、管理上ありえない。みんな一緒にしたいのは、デジタルファイルのプロジェクト管理の基本機能として、全部まとまってるのが大事だからだよ。デジタルファイルのバージョン管理や、リリース・ビルド計画との連携は必須なんだ。それが実際のプロジェクトの要求だね。デジタルアセットを含むプロジェクトは、バイナリや大きなデータファイルがつきものだし、テキストファイルだけってプロジェクトはむしろ珍しい。Linuxカーネルは、グラフィックとか大きな固定データがないから独特なんだ。Gitプロジェクトの全てが小さなテキストファイルじゃなきゃダメって考えは、マジで変だよ。ビデオゲーム、ウェブサイト、ウェブアプリ、データ駆動API、地理データ、画像、動画、音楽、ドキュメント…どれもバイナリファイルを使うでしょ？
選択肢は二つ。
1. Gitは、現実のプロジェクトに役立つ汎用VCSである。
2. Gitは、バイナリや大きなファイルを許可しない。
大きなファイルのバージョン管理って、そんなに複雑な問題じゃないんだ。差分やマージを気にしなくていいなら、管理はもっと簡単になるよ。

Git LFSがデフォルトでできないのは、次の理由からだね。
1. Gitとは別にインストールが必要。
2. GitフィルターやGitフックを使うから、ローカルでの設定が必要。
Gitに最初から組み込まれていれば、こんな問題は起きないのにね。

また同じこと言うけどさ、『俺の場合はリポジトリ全体をLFSに変換してた』って言ったじゃん。マニュアルの”INCLUDE AND EXCLUDE REFERENCES”ってセクションをチェックしてみてよ。

クラウドストレージからオブジェクトがなくなったり、ストレージが何度も移行されて、アーカイブに必要な古いストレージが使えなくなっちゃったらどうなるの？

そういう場合はエラーになるのは当然だよね、良くないけど。でも、元の人は、Git LFSにはネイティブなGitじゃ起こらない種類のエラーが他にもあるって指摘してたんだ。例えば、Gitアクションを途中で中断すると、Git LFSでは一貫性のない状態になっちゃうけど、ネイティブGitならそんなことは起こらないんだ。

Let’s Encryptは2012年に設立されて、2015年12月に一般公開されたね。Git LFSは2014年半ばだから、だいたい同じくらいの時代だ。

Gitが大容量ファイルの追跡に優れていないのが欠陥だとか、それが改善点だとかいう意見には反対したいね。

でも、もし問題がそれだけだったなら、LFSプラグインをGitのコア部分にすればよかっただけなんじゃないの？

OK、君の主な不満は、以前のコミット全てに.gitattributesが追加されることだったんだよね？もし誰かが昔のコミットに.binファイルを追加した場合、それでもLFSに入れたいと思うでしょ？“現在のコミットとの相互参照”がどういう意味なのか、俺にはちょっと分からないな。mainとか別のブランチの.gitattributesを使いたい理由も分からないし。明示的に指示されない限り、別のブランチを参照する操作って、すごくGitらしくない気がするんだけど。まあ、とにかく、LFSは履歴に適用しようとすると履歴を書き換えるのは確かだね。それが最善じゃないのは同意するよ。履歴をめちゃくちゃにして、特定のGitハッシュへのリンクを壊すリスクもあるしね。

大事なのは、二つの履歴を分けたくないってことだよ。もし君のユースケースが大容量ファイルにすごく依存してるなら、このユースケースにもっと向いている別のSCM（SVN、Perforceとか）を選ぶべきだね。でも、ファイルごとに違うSCMを使うのは、もう最悪な結果になるだけだよ。

ラージファイルを特別扱いする現在のGit LFSのような設計は根本的な問題だと思う。公式の新しいシステムも結局同じような振る舞いになりそうだよね。UXの問題は解決してほしいけど、Gitメンテナがちゃんと改善してくれることを祈るしかないなぁ。
自然に解決するとは思えないんだよね。

もし今の問題がなくなったら、それはもはやGit LFSじゃなくて、全然別のものになるんじゃないかな。

Git自体は良いツールなんだよ。ただ、このラージファイル管理の仕事には向いてないだけなんだ。

問題なのは、リポジトリでGit LFSを使い始めるのとは違って、移行する時にはメタデータが「過去に遡って」伝わることなんだ。
これじゃあ、実際のコミットにある内容が反映されないんだよね。

LFSってオフラインでの操作を壊しちゃうって話、僕も同じこと思ったよ。
Git annexはもっと分散的で、いろんなリモートにあるラージファイルの存在を追跡できるんだ。
USBドライブみたいなファイルシステムリポジトリからでもラージファイルを引っ張ってこれる。
でも、めっちゃ複雑で使いにくいのが欠点だよね。

この記事はGit LFSを不公平に扱ってると思うな。Git LFSはGitHubにロックインするわけじゃないし、プロトコルはオープンだよ。
Git拡張としてのLFSの欠点は避けられないんだ。PromisorsはLFSと同じコンセプトだけど、Gitに組み込まれてるからもっと良いUXを提供できるんだよね。

一度Git LFSをリポジトリで使うと、永久にロックインされちゃうんだ。
消費されたスペースを削除するには、GitHubからリポジトリを消すしかないって知ってた？
こんな振る舞いはどこにも明記されてないし、僕の会社でGitHubの統計調査してた時、ラージな圧縮データベースを保存するのに使ってて困ったよ。

これってGitとGitHubを混同してるよね。GitHubはひどいってのは今に始まったことじゃない。
Git自体は問題ないし、Git LFSはGitの拡張機能だよ。
Git LFSの仕様にはストレージの課金の話なんてないし、誰だってより良いサーバーを書けるんだから。

Gitの利用は圧倒的にGitHub経由だから、GitとGitHubを切り離して考えるのは難しいよ。
他の使い方はほとんど誤差みたいなものだしね。
だから、一番人気のGitホストで一番使われてるGitのラージファイル拡張機能が、ユーザーをロックインするってのは、知っておくべきめちゃくちゃ役立つ情報なんだ。

それって、すごく悪いロジックだよ。その論理だと、GitHubがダメだからGitもダメってことになるじゃん。みんながそれを混同するたびに、俺はイライラするんだよね。もっとちゃんと知ってるなら、なんで…？GitHubがダメだって言うだけでいいじゃん。

＞圧倒的にGitはGitHub経由で使われてる。他は誤差程度
これって本当？俺は商用でGitを5社で使ったけど、GitHubを商用で使ったことはないよ（オープンソースプロジェクトのプラットフォームとしては別だけど）。
GitHubにプロジェクトをホストしてたら、GitHubに依存してることになるけど、ロックインされてるわけじゃないよね？GitHubのリポジトリを閉じて、他のとこに移行できるんだから。何か見落としてるかな？

＞でもロックインされてない、他のとこに移行できるから。
Git LFSを使っていたら、リポジトリをフォークして書き換えて、.lfsconfigのバックエンドURLを更新しないと、まともに動く状態に戻せないよ。

＞そして問題は大きい：
＞高いベンダーロックイン – GitHubがGit LFSを作ったとき、他の大容量ファイルシステム—Git Fat、Git Annex、Git Media—はサーバーサイドに依存しなかった。でもGitHubは独自のサーバー実装にユーザーをロックインして、利用料を徴収した。
これって今でも問題なの？
俺は今週Git LFSをGitLabインスタンスで使ったけど、問題なく動いたみたいだよ。
https://docs.gitlab.com/topics/git/lfs/
その1週間前にもGiteaインスタンスでGit LFSを使ったけど、これも問題なかった。
https://docs.gitea.com/administration/git-lfs-setup
LFSが将来的に非推奨になるとかいう話を聞く一方で、使ってる人をほとんど見かけないから、みんな気にせず画像とかを普通のGitに突っ込んでるのが、なんか不思議なんだよね。

Gitコアでデカいファイルをサポートしてくれるのは本当に嬉しいよ。外部のソリューションだと、結局同じようなオプトインの手続きが必要になるしね。俺はできるだけコマンド少なく、シームレスに動いてほしかったから、APIは’.gitattributes’ファイルのsmudgeとcleanフィルターに限定したんだ。
ベンダーロックインをなくすために、AtlassianやMicrosoftとかなり早い段階から直接協力したんだ。特にAtlassianにはファイルロックAPIでたくさん助けてもらって、素晴らしい協力関係だったよ。LFSはオープンソースとして、3つの異なるGitホストで互換性ありでリリースされたんだ。

いや。これは解決策じゃない。
Git LFSは今のところごまかしに過ぎないし、クローン操作中にフィルター引数を書くのも長期的な解決策にはならないって。
git cloneって、ほとんどの人がGitを学ぶ時に最初に実行するコマンドじゃん？強調しとくけど、最初のコマンドだよ。
フィルターを書くことを覚えてくれるかな？多分、クールなコードベースのチュートリアルに書いてあれば覚えてくれるかもしれない。でも、もし書いてなかったら？気づかないまま時間がかかるかもしれない。もし覚えたとしても？クローンしたリポジトリはコンパイルできなかったり、使えなかったりするかもしれない。だってblobが欠けてるんだからね。
仮にちゃんとできたとしても、みんな理解できるかな？ほとんど無理だよ。俺たちはGitの内部構造を、みんなが最初に学ぶコマンドで晒してるんだ。「blobって何？」「なんでフィルターが必要なの？」「blobはどこに保存されるの？」って、まさに抽象化の漏洩じゃん。
これってRsyncがやってて、もう解決済みの問題だよ。その実装をただ持ってくるだけでいいんだ。つまり、代替の表現をサポートするか、blobを完全にやめるってことなんだけど、Gitのメンテナーたちはそうしたくないみたいだね。

＞これは解決済みの問題: Rsyncがやってる。
どんな解決策なのか説明してくれる？Rsyncアルゴリズムの詳細じゃなくて、ユーザーから見てどうなるのかを知りたいんだ。「git clone」したら、ローカルファイルシステムにどんなファイルがあるの？

シャロークローンならファイルは何も存在しないけど、フルクローンだと各バージョンの各blobがフルコピーで手に入るんだ。そして提案されてるのは、各リビジョンを最後のRsync操作として扱うってこと。ファイルをいじる回数が多いほど、それはアセットでもそうだし、コードの正確なスナップショットを取るために依存関係をチェックインした場合でもそうだけど、それがたくさんの大きなファイルの変更になるんだ。

画像や音声、動画みたいなほとんどのデカいアセットは、Rsyncアルゴリズムを使ってもメリットはほとんどないよ。ファイルをちょっと「調整」しただけでも、フォーマット的にはバイトレベルでめちゃくちゃ大きな違いが出ちゃうのが普通だからね。

動画はGitの範囲外かもしれないね。YouTubeですら動画の「更新」はできないんだから。
これ、めちゃくちゃ変に聞こえるかもしれないけど、動画のソースコードをスクリプトにしちゃって、ビルドするプロセスで動画を作って、それをリリース用の成果物にするのはどうかな？

Gitってさ、昔からフラグ追加して問題解決するけど、99%のユーザーはそんなの絶対見つけないよね。デフォルト設定を直そうとしないんだよな。後方互換性壊さずにデフォルトを変えることだってできるのにさ。

「デフォルトを直さない」ってのはちょっと違うんじゃない？Git 2.0でpushのデフォルト設定を”matching”から”simple”に変えたことあったじゃん。

Gitの肥大化ってほとんどが過去の履歴が原因って言うのは間違ってる？もしそうなら、最新バージョンのファイルだけをrsyncみたいにダウンロードするアプローチが一番いいんじゃないかな？ほとんどの人はそれだけで十分なはずだしさ。

「止まった時計が2度目に正しかったのはいつ？」って話だけど、俺は前のコメントに同意。Gitコミュニティって、チームの問題を解決するのに、デフォルト設定できないような一時しのぎの修正ばっかするんだよな。sparse checkoutとかコミット後のノート追加とかさ。これって、プルやプッシュするたびにめちゃくちゃ手間がかかるってことじゃん。IDEからは絶対使えないし。ホントの修正の邪魔をしてるだけだよ。

「Gitの肥大化ってほとんどが過去の履歴が原因？」ってのは、俺の経験からすると違うと思う。リポジトリをシャロークローンしても、容量の節約って思ったほどじゃなかったんだ。つまり、履歴はかなり効率的に保存されてるってことだね。

俺はGitが出たときから使ってるけど、IDEで使ったことなんて一度もないよ。ツールをちゃんと学ぼうとしないユーザーがターゲットになるべきなの？もちろん、インターフェースが大事じゃないとは言わないけどさ。俺はjqのインターフェースは最悪だと思ってるけど、Gitで同じように使いこなせないなんて想像できないんだよね。

ちょっと調べてみた感じだと、Gitはガベージコレクションで余計なファイルをちゃんと消してるから、前のコメントの「履歴は効率的」って話は合ってそう。でもさ、GitはMercurialみたいに差分じゃなくて、完全なファイルを保存してるんだよね。だから、やっぱり今のスナップショットだけを先にダウンロードするってやり方が効果あるかもな。

マジそれな！もしGitでデカいファイルが使えないなら、それはGitのバックエンドとかクローン機構が悪いってことだよ。そこをちゃんと直して、次のステップに進もうぜ。

「フィルターを書くの忘れる？」って話だけど、フィルターを書くのを忘れたって全然問題ないんじゃない？もし作業に10分以上かかってるなら、その時にフィルター書けばいいんだし。

「ビデオのソースコードはスクリプトで、ビルドしたらリリース版のビデオができるって、これってありえない話？」って提案だけど、実はそういうのってある程度もう実現されてるんだよ。でもそれって、すべての元映像にアクセスしなきゃいけないし、高品質でちゃんと圧縮されたビデオファイルをレンダリングするのにはめちゃくちゃ時間かかるんだよね。詳しくはこれ見て。
https://en.wikipedia.org/wiki/Edit_decision_list

これってかなりニッチだけど、アニメのファンエンコードで使われてるよ。一部のグループはVapoursynthスクリプトを公開してて、同じ元動画があれば同じ再エンコードができるんだ。例えば、LightArrowsEXEのEncoding-ProjectsやBeatrice-Rawsのencode-scriptsを見てみて。
https://github.com/LightArrowsEXE/Encoding-Projects
https://github.com/Beatrice-Raws/encode-scripts

え？なんで初心者に意味なく10分も待たせるわけ？自分が何間違えたのか、どれくらい待つのが普通なのか、どうやって分かるの？ChatGPTに「Gitクローンが10分かかるのはなぜ？」って聞けってこと？！ユーザー体験としてこれがベストなわけないよ。Gitはもっと改善する必要があるね。

まさにそれだよ、今回の変更で対応してるんだけど、デフォルトにならないのは、多くの人がGitにテキストしか置いてないから、これらの変更によるデメリットを避けたいんだよね。

Gitは論理的には完全なファイルを保存するモデルだよ。でも物理的には、これらの完全なファイルはpackファイル内で差分（deltas）として保存されてるんだ。まだパックされてない新しいファイルは別だけどね。デフォルトでは、Gitはたくさんのloose filesがあると自動的にパックするし、ネットワークプロトコルで送受信するときも常にパックされるよ。

手動フィルターが最善策かは分からないけど、これで多くの足りない部分が補われる気がするね。Gitの初回コミット時みたいに、デフォルトのグローバルフィルターサイズに引っかかるリポジトリをクローンした時に、無効化する方法を教えてくれると良いな。「クローンしたリポジトリはブロブがないからコンパイル/使用できないかも」ってあったけど、LFSみたいに大きいファイルの全履歴ダウンロードを防いで、必要なバージョンだけチェックアウトするのがフィルターの目的なんじゃないの？1バイトのフィルターでもワーキングツリーは使えるけど、過去のコミットをチェックアウトしようとすると全ファイルダウンロードが必要になるってことかな。

うーん、動画自体は「アニメX シーズン1 第5話」みたいなインデックス可能な識別子で参照されるんだろうね。実際の動画のプロビジョニングは、ビルドする人が（多分Torrentネットワークか、誰もやらないだろうけどDVDから）入手することになるんだろうな。

それは「ビルド」を瞬時に終わるもの、あるいは数時間で完了するものと見なす場合に限った問題だね。科学における再現性と似てるよ。LHCみたいに再現がとてつもなく高価な実験もあるけど、技術的には再現可能なんだ。

「クローンしたリポジトリはブロブがないからコンパイル/使用できないかも」って話だけど、ブロブの履歴だけがフィルターされるんだよ。

多くの動画編集って、動画全体の作り直しじゃなくて、一部の映像を繋いだり削除したりすることなんだよね。こういう使い方なら、ローリングハッシュを使うrsyncがすごく役立つはずだよ。