documenting my sufferings with git submodules
This commit is contained in:
parent
b34621d0f7
commit
a51f888501
@ -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,
|
||||
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
|
||||
a very long time, and GitSubmodules allows this to scale, because the
|
||||
local great big pile of source code references many independent and
|
||||
|
Loading…
Reference in New Issue
Block a user