"Boespflug, Mathieu"
If the status quo is poor, then why not merge the two? git-subtree won't fix the problem and will arguably be even harder to manage than submodules.
The status quo is indeed awkward at times. However, merging Haddock into GHC would only serve to shuffle this awkwardness to be felt by a different group of people. Currently the awkward workflow is contributing a GHC patch that affects the subset of GHC's AST that Haddock cares about. This is unfortunate but not unexpected; working with coupled systems always brings challenges. However, this is not the common case. If we were to merge Haddock into GHC then we make harder the lives of those who work on Haddock independently from GHC. All Haddock changes would need to go through the GHC tree, we would need to setup special CI rules to run only the haddock testsuite, and the histories of the two orthogonal projects would be awkwardly coupled. Given that most of the commits in the haddock repository are independent from GHC this seems like a poor trade-off. As a general rule I think we would be better off trying to loosen GHC's coupling to other projects than further entrench them. Cheers, - Ben