Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
kazu at iij.ad.jp
Wed Apr 16 06:09:40 UTC 2014
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
More information about the ghc-devs
mailing list