Haddock workflow needs improvement (git-subtree)
Problem
There appears to be no good workflow for contributing patches that change both GHC and Haddock.
For contributors who have push access to both repositories, it is at least tolerable:
- create a Haddock branch with the required changes
- create a GHC branch with the required changes
- wait for the GHC change to get merged to
master
- fast-forward the Haddock change to the
ghc-head
branch; in case a fast-forward is impossible, cherry-pick the commit toghc-head
and push another commit to GHCmaster
to update the Haddock submodule
Roundabout, but possible.
For contributors who do not have push access to both repositories,
each step is much harder, as working with forks implies messing with
.gitmodules
, which arguably should stay constant.
Proposed solution
- on GitLab we have a full copy of
haddock
(via git subtree) inside GHC's repository, the development is done there. - on GitHub we no longer have the
ghc-head
branch, but contributors can create PRs againstghc-8.6
or whatever is the latest release - once per release, we do a
git subtree push
to create a new release branch on the GitHub's repo - in GHC, when backporting commits to minor releases, we do
git subtree pull
to get the relevanthaddock
changes
This means that the main workflow doesn't even require dealing with git subtree
, it's only backporting/release when it matters. The rest of the time one can pretend that haddock
lives in the GHC's repo.
Note: none of the above applies to the Cabal submodule. Cabal isn't tied to a particular GHC version, so whatever changes are made there should work both before and after corresponding GHC commits. It means that one can do Cabal's changes first, GHC's second, no atomicity required.