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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
