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

[Herbert Valerio Riedel]

On 2014-04-15 at 05:38:54 +0200, Kazu Yamamoto (山本和彦) wrote:
> Hi Herbert,
>
>> After a short conversion with Austin and Edward it appears that the
>> sensible course of action with respect towards moving to a proper Git
>> submodule set-up is to fold-in the 5 Git repos listed below (which btw
>> are all GHC wired-in packages) directly into ghc.git (the same way
>> testsuite.git was a few months ago):
>
> This is just a confirmation. I have no opinion on this.
>
> Recalling the discussion in the last summer, I understood GHC project
> will start using git subtree, not git submodule. But it seems to me
> this is my misunderstanding.
>
> What was the conclusion of that discussion? And would you tell me why
> submodule was chosen?

I believe you refer to

 http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1179

and the spin-off thread

 http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1237

However, I couldn't find any conclusion while skimming through the
threads stating that using 'git subtree' would have been the conclusion.

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