Herbert 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! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@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@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs