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

Simon Peyton Jones simonpj at microsoft.com
Tue Mar 18 12:25:00 UTC 2014


I really appreciate the work you are doing here -- thank you.

As a client, though, I'm very ignorant about submodules, so I do need education about the work-flows that I should follow.  If there are things I must or must not do, I need telling about them.

Much is taken care of by sync-all, which is great.  If that continues to be the case, I'm happy!


| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 18 March 2014 10:59
| To: ghc-devs
| Subject: HEADS-UP: new server-side validation git hook for submodule
| updates & call-for-help
| 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
|   https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4
| (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.
| Cheers,
|   hvr
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

More information about the ghc-devs mailing list