Version 73 (modified by hvr, 5 years ago) (diff)

use proper wiki page-ref syntax

GHC Repositories

This page lists the active repositories relating to GHC. For instructions on actually getting a GHC source tree, see Getting The Sources.

For read-only browsing, you can use the:

For info on the active branches of the main GHC repo, see

GHC's repos use git; see Git Working Conventions.

Be sure to read more on the working conventions for submodules, which are thoroughly documented here

GHC Repositories

The GHC source code tracks many related sub-repositories, which are needed for external dependencies during the build, or tools that are included in the build. Not every sub-repository is maintained by us; in fact, the large majority are not maintained by GHC HQ.

As a result of this, in HEAD, essentially every single upstream repository we track is tracked with a git submodule. These submodules are mirrored for us, and we send patches we need to the upstream maintainer.

But what happens if you need to get a submodule updated? It's quite simple...

Sending patches upstream, the short version

  • Send a patch upstream. Get it merged.
  • Once that is done, just update the submodule:
cd libraries/foo
git reset --hard some_commit_id
cd ../..
git commit -asm "Update foo submodule"
./sync-all push

where some_commit_id should be the commit ID of the change you pushed. For example, if you pushed three changes (where 'Commit #3' is the latest HEAD):

026d0f64723729823ef29991218c7a15d8d37264 - Commit #1
235da0f3e38c2b4c489a82778a5fd84a895cb693 - Commit #2
0667f01823552caf97c4d6e8b876b1d9db00a172 - Commit #3

then some_commit_id = 0667f01823552caf97c4d6e8b876b1d9db00a172

  • Done!

Submodule reference validation

There is a problem with submodules, in that it would be possible to commit a submodule change to ghc.git, which points to an invalid commit. For example, perhaps you make a change to haddock and ghc. You might accidentally push to ghc before pushing to Haddock, or worse, you might forget.

For this reason, the GHC repository has commit hooks that validate submodule references. Any time you update a submodule, you must:

  • Have already pushed the new changes upstream, in a way git can find them.
  • You must include the word 'submodule' in your commit message.

If either of these assumptions are violated, your push will fail.

Full repository breakdown

A GHC source tree is made of a collection of repositories. Here is a list of the repositories that GHC uses. The columns have the following meaning

  • Location in tree: where in the source tree this repository sits.
  • Upstream repo?: if "yes", this library is maintained by someone else, and its master repo is somewhere else. See Repositories/Upstream.
  • Reqd to build?: is "no" if this library is not required to build GHC. We have a few of these because we use them for tests and suchlike.
  • Installed?: is "no" if the library is not installed in a GHC installation, and "extra" if it is only installed if InstallExtraPackages is YES. All others are installed with GHC. See the libraries page for more info.
  • GHC repo: in every case there is a repo on, which contains the bits we use for building GHC every night. For libraries with upstream repos, this is just a lagging mirror of the master (see Repositories/Upstream). The read-only HTTP URL for the repo is<table-entry>. To get a read/write URL, replace HTTP prefix with the SSH prefix ssh://

This table might be out-of-date: for guaranteed up-to-date info, check the packages files.

Location in tree Upstream repo? Reqd to build? Installed? GHC repo
. (ghc itself) ghc.git
ghc-tarballs N/A ghc-tarballs.git
utils/hsc2hs hsc2hs.git
utils/haddock yes haddock.git
nofib N/A nofib.git
libraries/array packages/array.git
libraries/binary yes packages/binary.git
libraries/bytestring yes packages/bytestring.git
libraries/Cabal yes packages/Cabal.git
libraries/containers yes packages/containers.git
libraries/deepseq packages/deepseq.git
libraries/directory packages/directory.git
libraries/filepath packages/filepath.git
libraries/haskeline yes no packages/haskeline.git
libraries/haskell98 packages/haskell98.git
libraries/haskell2010 packages/haskell2010.git
libraries/hoopl packages/hoopl.git
libraries/hpc packages/hpc.git
libraries/old-locale packages/old-locale.git
libraries/old-time packages/old-time.git
libraries/pretty yes packages/pretty.git
libraries/process packages/process.git
libraries/terminfo yes no packages/terminfo.git
libraries/time yes packages/time.git
libraries/transformers yes packages/transformers.git
libraries/unix yes packages/unix.git
libraries/utf8-string yes packages/utf8-string.git
libraries/Win32 yes packages/Win32.git
libraries/xhtml yes no packages/xhtml.git
libraries/random yes no no packages/random.git
libraries/primitive yes no no packages/primitive.git
libraries/vector yes no no packages/vector.git
libraries/dph no no packages/dph.git
libraries/parallel no no packages/parallel.git
libraries/stm no no packages/stm.git

Mirroring new packages to GitHub

Currently, all our repositories are being mirrored to GitHub by GitHub themselves. If you wish to add/remove a repository you need to email GitHub support at support@… and ask them to do it. Currently there is no way to administer this ourselves.