documenting my sufferings with git submodules

This commit is contained in:
Cheng 2022-06-11 15:45:06 +10:00
parent b34621d0f7
commit a51f888501
No known key found for this signature in database
GPG Key ID: D51301E176B31828

View File

@ -77,6 +77,18 @@ repository results in non portable surprises and complexity. Makes it hard
for anyone else to build your project, because they will have to, by hand, for anyone else to build your project, because they will have to, by hand,
tell your project where the libraries are on their system. tell your project where the libraries are on their system.
When one is developing code, you normally have a git branch. But
the git commit of the master project in which the submodule is
contained refuses to point to a branch. For ones changes to a
submodule to be reflected in the master project in any consistent or
predictable way, the submodule has to be in detached head mode,
with the head pointing directly to a commit, rather than pointing to
a branch that points to a commit.
This means that signing off on changes to a submodule is
irrelevant. One signs off on the master project, which includes the
hash of that submodule commit.
You need an enormous pile of source code, the work of many people over You need an enormous pile of source code, the work of many people over
a very long time, and GitSubmodules allows this to scale, because the a very long time, and GitSubmodules allows this to scale, because the
local great big pile of source code references many independent and local great big pile of source code references many independent and