Git Submodules はパッケージマネージャーとして機能するのか？11年経っても解決されない根本的な欠陥
Git Submodules as a Package Manager
Git Submodules をパッケージマネージャーとして評価した記事。ロックファイルとしての gitlink、マニフェストとしての .gitmodules という構造は備えるものの、依存関係の解決、インストール、ストレージ、更新、セキュリティの各面でパッケージマネージャーとしての完成度に欠ける。特に、worktree との併用で問題が顕在化し、11年前の注意喚起から現在まで改善されていない点を指摘。CVE-2018-11235 などのセキュリティ脆弱性の例も挙げ、抽象化の欠如が根本原因だと論じる。
サブモジュールは Git の内部構造をそのまま露出している。パッケージマネージャーはそれらをマニフェスト形式、リゾルバ、ローカルキャッシュの背後に隠すが、サブモジュールはそれらを生のまま表面に出す。
HNでの議論
33- unqueued
ちなみに、サブモジュールはgitfileと対応する`$GIT_DIR/modules/<name>`を使う必要はなく、使わないほうが良い理由もあります。サブモジュールに'.git'があれば、それはシンボリックリンクでも、自己完結型の埋め込みリポジトリとして通常の.gitディレクトリでもかまいません。親リポジトリで同じgitlinkを使ってコミットIDを表すことができ、gitはそれを管理します。
20GBのサブモジュールがある場合、通常は`git clone <url> <path> && git submodule add <path>`を実行するだけで、gitは同じように扱います。しかし、これなら削除するだけで完全に消去できます。また、gitfileを逆参照しないので、ある意味でより移植性が高く、壊れにくいです。私はリポジトリがよりボトムヘビーで、モジュールフォルダを詰まらせない方が好みです。
`git submodule absorbgitdirs`の逆を行う大まかなスクリプトを持っていますが、少し壊れやすいです。
これをより公開するための配管があると便利でしょう。
- dissent
パッケージマネージャーがgitリポジトリを指してパッケージとして使えるなら、それは偶然の便利さにすぎません。ソースコードリポジトリはソースコードとして構成され、それをパッケージに変換するビルドステップを持つべきです。言語によってはコンパイル、トランスパイル、ミニファイ、または単にファイルのコピーを意味します。結果として得られる成果物は、消費用に設計された異なる形です。
gitをパッケージに使うと、リポジトリがパッケージの境界になります。単一のリポジトリから複数のパッケージを生成するオプションや、複数のリポジトリから単一のパッケージを生成するオプションがなくなります。
- AlphaSite
おもちゃだとは思いますが、もし誰かがこれを本気でやろうと思ったら、npmから学んで、プロジェクトのクローンごとにパッケージを複製しないでください。まともなパッケージマネージャーのように、プロジェクト間で共有してください。
- Myrmornis
サブモジュールに関する混乱や批判の多くは、それを使うために多くの新しいコマンドを学ぶ必要がないことを理解していない人々から来ています。サブモジュールにcdして、通常のgitリポジトリとして使うだけです。それからcdして戻り、必要ならサブモジュールのハッシュ変更をコミットします。
削除など、いくつかのことは面倒です。しかし一般的には、それらは非常に有用で、基本的にあなたが望むように設計されています。サブモジュールの中に入ると、通常のgitリポジトリとほぼ同じように動作するので、非常に一貫性があります。
- orliesaurus
開発者体験が同じではないだろうという気がしますが、それはおそらく一時的な問題にすぎないでしょう？