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
| (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 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.
| : 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.
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs