Work as a "link", submodules are separate repositories within direcotry tree of parent repository, "the only linkage...is recorded value of the submodule's checked-out SHA is stored in parent's commits", to update the link, "git submodule update".
In merging, also need to do "git submodule update" otherwise not updated that SHA link and still with previous submodule commit. Also since only SHA is recorded, git parent repository just treat the submodule a big binary.
git submodule update - silendly overwrite instead of merge
make some change, commit, this did not commit own submodule change to parent project yet
git submodule update - it would overwrite if someone else made changes
"remember to commit all changes (and push?) before running git submodule update"
git status in parent - does not include detailed changes of submodules
git log - submodule changes show up in one single message despite lots changes
shell commands - lots to do and "first commit all the changes in submodules!"
It uses git's "subtree merge" function. It actually store the files in the main repository (not just a SHA link) and merge in changes directly to that repository.
Many article suggests subtree less evil than submodule.
One down side is parent repository becomes big.
Rebase with subtree sounds very difficult...
Does not store the URL of the sub module...
Complicated to send back changes to sub module