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 git.haskell.org, which can be accessed via,
email@example.com (for those with commit access)
These are also mirrored to GitHub under the ghcorganization. Note that we do not use GitHub as the primary upstream since GitHub does not allow us to use Git hooks. These hooks are invaluable for verifying consistency between submodules (e.g. that the ghc repository refers only to submodule commits which are available upstream, see #8251).
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:
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.
If the upstream repo is not at git.haskell.org, then we maintain a mirror repo at git.haskell.org.
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:
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"
 These libraries are not installed in the resulting compiler when you do make install
 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/build.mk. You can skip haddock by setting HADDOCK_DOCS=NO in mk/build.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.
The transformers library's upstream uses darcs. In order to track this library, we maintain a git mirror (http://git.haskell.org/darcs-mirrors/transformers.git) generated using darcs export mirror which is periodically updated by git.haskell.org. However, due to the tendency for the import mechanism to produce non-fast-forward branches, the commits in this mirror need to be manually pulled into the submodule used by GHC, firstname.lastname@example.org:packages/transformers.
There are a also a variety of repositories which contain infrastructure-related bits. These include,