I agree with Geoff, submodules bring a certain complexity, but also advantages. We already pay for most complexities if we use submodules at all (such as having to use "git submodule" and remember to keep them in sync). If we pay already, why not reap the advantages for the rest of the repositories as well.
For example, I often make changes in the main repo and the dph repo at the same time. It would be much more convenient if a branch would reflect the shared state of both (i.e., if dph would be a submodule of the main repo). In other words, if we use submodules at all (which is an idea I like), why add additional complexity by using different mechanisms for different subrepos? And why not reap the benefits of submodules across the board? Manuel Geoffrey Mainland <mainl...@apeiron.net>: > On 11/02/2012 08:10 PM, Ian Lynagh wrote: >> Hi all, >> >> We have been working on a new way in which we handle the repositories >> that make up a GHC tree, in order to makes the process smoother for all >> parties. >> >> Our proposal is here: >> http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Repositories >> >> Please have a look and let us know what you think, and especially >> whether you think there is anything that we've failed to take into >> account. >> >> Thanks >> Ian > > Hi Ian, > > Thanks for putting together the proposal. > > If we will now be using git submodules for external libraries, can we > not just use submodules for all libraries? That way the GHC repo hash > will uniquely specify everything needed to reproduce a build. Right now > it is painful to do any sort of bisect operation---doing so requires > digging through build logs to find fingerprint files for past builds. > > It looks like the proposal will leave us with the pain of fingerprints > and add the additional pain of git submodules. I am very much in favor > of just using submodules for everything. > > Geoff > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
