HEADS-UP: new server-side validation git hook for submodule updates & call-for-help

Herbert Valerio Riedel hvr at gnu.org
Tue Mar 18 10:58:36 UTC 2014

Hello *,

I've put in place a new server-side validation hook a few days ago, and
since nobody seemed to have complained yet, I assume it didn't have any
adverse effects so far :-)

It will only be triggered when Git submodule references are touched by a
commit; you can find some preliminary (but incomplete) documentation and
a sample session triggering validation-failure on purpose at


(this will be turned into a proper wiki-page once #8251 is completed;
there's some minor details wrt some corner cases that still need to be
looked at)

So, this mostly addresses the server-side requirements for migrating to
a proper git-submodule set-up for ghc.git;

The next steps, however, include taking care of the client-side work-flow
for working with a fully "submoduled" ghc.git setup. Personally, I'm
quite comfortable using direct git commands to manage such a construct,
but I'm well aware not everyone is (as previous discussions here have
shown). Also, as my time is rather limited, I'd like to ask interested
parties to join in and help formulate the future client-side work-flow[1]
and/or update (or rewrite) the 'sync-all' to provide a seamless or at
least smooth transition for those GHC devs who want to keep using
"sync-all" instead of using direct Git commands.

 [1]: There's some difference in how tracked upstream packages and
      GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid
      ending up with a noisy ghc.git history. 

      For instance, having ghc.git with submodules is not the same as
      having a huge monolithic ghc.git repository with all subrepos
      embedded. specifically, it might not be sensible to propagate
      *every* single subrepo-commit as a separate ghc.git submod-ref
      update, but rather in logical batches (N.B.: using submodules
      gives the additional ability to git bisect within subrepos instead
      of having to bisect always only at top-level). This is one example
      of things to discuss/consider when designing the new work-flow.


More information about the ghc-devs mailing list