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,
|
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
|
||||||
|
Loading…
Reference in New Issue
Block a user