Hi Herbert, Thank you for your kind explanation! --Kazu
Otoh, I can offer part of the motivation for using `git submodules` from my current point of view from the top of my head:
- We already use Git submodules for half the sub-repos, using a mix of submodules and subtrees might become too confusing.
- The remaining (after the wired-in packages are folded in) non-yet Git-submoduled repos at git.haskell.org are candidates for being moved to http://github.com/haskell/ (most are not specific to GHC (in theory at least) and are to become managed more actively by the core library committee, read "outsourced"), so they'd essentially become 3rd party tracked upstream repos, which is exactly the use-case that Git submodules are suited for.
- Git subtrees embed the sub-repos' content into the super-repo, therefore once you don't need the subrepo anymore, you still have to carry around its content forever in the superproject. Git submodules only require to store the sub-repos commit-ids in the the super-repo
(Git Submodules are basically what GHC fingerprints would provide if the GHC fingerprint would be checked into ghc.git and kept up-to-date with each ghc.git commit)
- Git subtree is actually a Git contrib-script and may not be available in all Git installations. Submodules, otoh, have been an integral part of Git since version 1.5.3
Cheers, hvr