TFAは、Git LFSが悪い理由をいくつか挙げていて、その中にはベンダーロックインのような独自性があるからって言ってるけど、それはちょっと unfair だと思う。GitHubはオープンなクライアントとサーバーを提供してるから、その点は否定されるよね。LFSはオフラインやスニークネットの操作を壊しちゃうけど、それはニッチなワークフローだし、あんまり言及されてないのが残念。でも、プロミサーでも同じように壊れそうだね。git partial cloneの例は面白い！Large Object Promisorsの説明を読むと、LFSのクライアント側の複雑さをサーバー側に移して、さらに複雑にしてるように聞こえる。クライアントがgitサーバーにアップロードして、そこからオブジェクトストアにアップロードする代わりに、クライアントはオブジェクトストアから直接ダウンロードするってこと？明らかにトレードオフがあるよね。公共のgitサーバーにアップロードすることで、隠れたプロミサーリモートに引っかかることがどれくらいあるのか気になるな。

いや、これは解決策じゃないよ。今のところgit LFSはただの妥協策だし、クローン操作中にフィルター引数を書くのも長期的な解決策じゃない。Git cloneは、ほとんどの人がgitの使い方を学ぶときに最初に実行するコマンドだからね。強調しておくけど、最初のコマンドだよ。フィルターを書くことを覚えてるかな？多分、アクセスしようとしてるクールなコードベースのチュートリアルに書いてあれば覚えるかも。でも、書いてなかったらどうなる？明らかに何かが足りないのに、長い時間待たされるかもしれないし。もし書けたとしても、クローンしたリポジトリがコンパイルできなかったり使えなかったりするかもしれない。もしうまくいったとしても、理解できるかな？たぶん無理だろうね。最初に学ぶコマンドでgitの内部動作をさらけ出してるんだから。ブロブって何？なんでフィルターが必要なの？ブロブはどこに保存されてるの？これは典型的な抽象化の漏れだよ。この問題は解決済みで、rsyncがやってることなんだから。実装をそのまま移植すればいいだけなのに。代替表現をサポートするか、ブロブから完全に離れる必要があるけど、gitのメンテナーたちはそれをやりたがってないみたい。

ちょっとした指摘：> もし25MBのうるさいPNGファイルの多くのリビジョンを持つリポジトリをgit cloneしたら、FYI「うるさい」は「ノイジー」の同義語じゃないよ。「有害な」って意味で、何かが悪臭を放ってるってことだよ。

Gitのコアで大きなファイルのサポートが見られて本当に嬉しいよ。外部のソリューションも同じようなオプトイン手続きが必要だしね。できるだけ少ない追加コマンドでシームレスに動いてほしかったから、APIは「.gitattributes」ファイルのsmudgeとcleanフィルターに制約をかけたんだ。でも、プロセスの初期段階でAtlassianやMicrosoftと直接協力して、ベンダーロックインを取り除くために頑張ったよ。特にファイルロックAPIについてはAtlassianからたくさん助けてもらったし、素晴らしい関係だった。LFSはオープンソースで、3つの異なるGitホストで互換性のあるサポートが提供されたんだ。

大きなオブジェクトのプロミッサーは、大きなファイルだけを扱う特別なGitリモートなんだ。このアプローチ、いいと思う。もしS3みたいなものを使えるようにリポジトリを設定できたら、LFSを使うのをやめるかも。S3はVCSの大きなバイナリにとって本当に良いシナジーのように思えるし、インテリジェントなティアリング機能は、歴史が自然に蓄積されて古いものが忘れられるにつれて、データを冷たいストレージに移動してくれる。10年前のデータを引っ張るために、歴史的なチェックアウトに半日かかっても気にしないよ（ロボティックテープライブラリから復元する場合ね）。

Gitがシャロークローンとパーシャルクローンを直してくれたらどうかな？そうすれば、ポインタやプロミスの歴史を完全にクローンした後に大きなコンテンツを不正に追加するための複雑な回避策が必要なくなるよ。ファイルタイプやサイズごとにデフォルトのクローン深度を設定できるようにしたいし、Git属性で（もしくはリポジトリの上に存在できるファイルで、.gitconfigの場所にサポート属性を持つファイルとか？）設定できるといいな。通常の設定は、最新のコンテンツをシャロークローンしつつ、全履歴やテキストファイルの歴史的コンテンツも取得するって感じで。理想的には、クローン深度設定に合わせてプルーニングもできるといいね。なんでまだ大きなファイルポインタの話をしてるんだろう？シャロークローンとパーシャルクローンを直せば、どんなリポジトリも効率的なファイルミラーになれるよね？

この記事はLFSを不当に扱ってるよ。GitHubにロックインされるわけじゃないし、プロトコルはオープンなんだから。LFSの欠点はGit拡張として避けられないものだよ。プロミッサーは基本的にLFSと同じ概念だけど、Gitに組み込まれてるから、拡張としては実現できないより良いUXを提供できるんだ。

oxenを開発中で、gitやgit-lfsで直面した多くの問題を解決しようとしてるよ。gitをミラーリングするオープンソースのCLIとサーバーがあって、大きなファイルや何百万ものファイルを持つモノリポをもっとパフォーマンス良く扱えるんだ。興味があったらフィードバックもらえると嬉しいな！ https://github.com/Oxen-AI/Oxen

ソフトウェアエンジニアリングのクラスでおすすめしてたのは、大きなファイル（メディアとか）をGitに入れるんじゃなくて、アーティファクトリポジトリ（Artifactoryとか）に入れること。そうすれば、ビルドシステムが自動で取得するスナップショット依存関係として公開できるし、どれだけの履歴を保持するかをコントロールできる。さらに、同僚には最新バージョンだけを取得させればいいから、古いバージョンが使ってたスペースを解放するためにビルドシステムのキャッシュを簡単にクリーンできるんだ。

3Dモデル用にPlastic SCMの代替が本当に欲しいな。S3でもいいけど、ちょっと物足りないんだよね。