That second article is a bit preachy. The `git submodule` command exists
for a reason, and I would trust it over any of the 3rd-party alternatives.
That said, it can be a bit finicky to work with at times. The key to
remember is that the parent project always points to a *snapshot* (i.e., a
commit) of the submodule repository, not a branch. This has a couple of
potentially annoying side effects:
1. Upstream commits from the submodule will not automatically be reflected
in the parent repository. You have to manually go in and update the commit
reference in the parent project. However, the advantage of this behavior is
that you can check out or revert to a previous commit in the parent project
and get its *exact* state, which is not possible if each commit references
a *branch* in the submodule.
2. As noted in that second article, the submodule will typically be in a
detached head state, which means you need to be careful about committing
changes directly in a submodule (this is not a problem if you are only
working on the submodule repos in isolation and using `git submodule` to
pull upstream changes into the parent project).
The official docs cover all of this in much more detail.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.