Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git

Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) kazu at
Wed Apr 16 06:09:40 UTC 2014

Hi Herbert,

Thank you for your kind explanation!


> 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 are candidates for being
>    moved to (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