Version 9 (modified by batterseapower, 9 years ago) (diff)


Converting from Darcs

Conversion status



Dependencies on darcs

The following is intended to be a complete list of the things that would need to change if we were to switch away from darcs, in addition to the conversion of the repository itself, which I am assuming can be automatically converted using available tools.

The following code/scripts would need to be adapted or replaced:

  • The darcs-all script
  • The push-all script
  • The aclocal.m4 code that attempts to determine the source tree date
  • .darcs-boring
  • The buildbot scripts
  • checkin email script: /home/darcs/bin/
  • Trac integration (the GHC Trac does not currently integrate with darcs, however)
  • darcsweb (use whatever alternative is available)

The following documentation would need to change:

Plan for libraries

The remaining question is what to do about the library repositories. It is possible to work with the GHC repository in git and all the other repositories in darcs, but this can't be a long-term strategy: our motivation for moving away from darcs is invalid if parts of the repository still require darcs. We need a strategy for a single-VCS solution.

Here's a tentative plan:

  • Some libraries belong to GHC (template-haskell, ghc-prim, integer-gmp, hpc), and for these we can convert the repos to git and keep them as subrepos. (alterantively we could just import them into the main git repository for convenience).
  • Of the rest, base is somewhat special, because this alone often needs to be modified at the same time as GHC. We propose migrating base to a git repository.
  • For the rest of libraries (e.g. filepath, containers, bytestring, editline), GHC is just a client, and we don't expect to be modifying these libraries often. Hence we can just copy the libraries wholesale into the GHC git repository, and update the copies occasionally when a new version of the library is released. We can provide a way to update the GHC copy from the official darcs repository easily. The local copy would be read-only, except when updating from the master copy.

The perspective on submodules

Submodules do not really seem to be designed for what we want to do (work on a cohesive set of components that are developed together): they seem more suited to tracking upstream branches that you do not modify locally.

However, if we did want to use them there is a git-rake tool that provides many of the submodule commands to do this that are missing from Git proper: See also the discussion on his blog at

An alternative approach seems to be using a single repo and the "subtree" merge strategy. There are some tools for making this work nicely with external repositories, such as and what looks like a nice tool called Braid

Attachments (13)

Download all attachments as: .zip