Ben, 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. Ryan -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
