GHC Repositories

This page lists the active repositories relating to GHC. These are Git repositories, so you should learn about Git first. For instructions on actually getting a GHC source tree, see Getting The Sources. For information on using these repositories (via submodules), see the Submodules page.

Many GHC repositories and its core packages can be found at, which can be accessed via,

  • git://
  • (for those with commit access)

The SSH host keys of are,

  • ecdsa: 91:4e:95:fa:2e:34:6c:ba:68:af:71:29:ba:66:12:b0
  • rsa: 08:63:b5:86:3e:ae:e2:3c:b1:ea:c6:05:2d:71:db:5a

Repository listing

The GHC source code uses many related sub-repositories, which are needed for external dependencies during the build, or tools that are included in the build. Every single upstream repository we track is tracked with a git submodule, so that for any particular GHC commit, Git's submodule mechanism makes it possible to check out exactly the right version of each sub-repository.

Some submodules are maintained by GHC HQ, and some by their parties. You can find out by looking at the .cabal file.

Here is the setup in more detail:

  • Upstream repo.
    • Each submodule has an upstream, or master, repository.
    • Patches to the submodule must be pushed to the upstream repo.
    • The authoritative info for the upstream URL is in the file packages in the root directory of the main GHC repo.
    • If the packages file gives an upstream URL of "-", authoritative info is in the file .gitmodules.
  • Mirror repo.
    • If the upstream repo is not at, then we maintain a mirror repo at
    • Pulling and cloning happens from the mirror repo, so that we can build GHC without relying on lots of other machines being up.
    • The mirror should be updated from the upstream repo at least every minute or so.
    • The authoritative info for the mirror URL is in the file .gitmodules in the root directory of the main GHC repo.
  • Upstream GHC branch (see table below).
    • As GHC's HEAD moves on between releases, there is often a need to update a library in sync. Each library has a named branch, the upstream GHC branch to which patches can be pushed.
    • If the library author is actively developing the library, he or she will typically do so on a different branch from the upstream GHC branch, to avoid discombobulating GHC HEAD.
  • Updating sub-repos. If you want to update a library to track some change in GHC HEAD, the sequence typically looks like this:
    • cd libraries/parallel
    • git checkout master, or whatever the "upstream GHC branch" is called. Previously the submodule would be in a detached-head state.
    • Make modifications to the library
    • git push: push the patch to the upstream repo (may need to ask the maintainer to do this)
    • cd ../..: back into the GHC directory
    • git add libraries/parallel: record the new library commit in the main GHC repo.
    • git push, with a commit message mentioning the word "submodule"

More details in the Submodules page

Here are the submodules we use, and where their upstreams point:

Location in tree Upstream repo Upstream GHC branch Installed[1] Req'd to build[2]
utils/hsc2hs master Yes Yes
utils/haddock ghc-head Yes No
nofib master N/A N/A
libraries/array master Yes Yes
libraries/binary master Yes Yes
libraries/bytestring master Yes Yes
libraries/Cabal master Yes Yes
libraries/containers master Yes Yes
libraries/deepseq master No No
libraries/directory master Yes Yes
libraries/filepath master Yes Yes
libraries/haskeline master Yes Yes
libraries/haskell98 master Yes Yes
libraries/haskell2010 master Yes Yes
libraries/hoopl master Yes Yes
libraries/hpc master Yes Yes
libraries/old-locale master Yes Yes
libraries/old-time master Yes Yes
libraries/process master Yes Yes
libraries/terminfo master Yes Yes
libraries/time ghc Yes Yes
libraries/unix master Yes Yes
libraries/Win32 master Yes Yes
libraries/xhtml master Yes Yes
libraries/random master No No
libraries/primitive master No No
libraries/vector master No No
libraries/dph master No No
libraries/parallel master No No
libraries/stm master No No
  • [1] These libraries are not installed in the resulting compiler when you do make install
  • [2] These libraries are not required to build the compiler, but may be used for tests or other libraries. Right now, most of these are based on whether you build DPH. At the moment, DPH is turned off. To build these libraries, set BUILD_DPH=YES in mk/ You can skip haddock by setting HADDOCK_DOCS=NO in mk/ TODO Explain how to skip deepseq, since it seems to only be used for tests.

The table above is maintained manually and can sometimes get out of sync. If in doubt, the primary data source is the packages file in the top-level ghc.git repo folder.


There are a also a variety of repositories which contain infrastructure-related bits. These include,

Last modified 5 months ago Last modified on May 10, 2017 1:00:33 PM