On 01/13/2011 12:49 AM, Simon Marlow wrote:
I spent quite some time yesterday playing with submodules to see if they would work for GHC. I'm fairly sure there are no fundamental reasons that we couldn't use them, but there are enough gotchas to put me off. I wrote down what I discovered here:
http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules
I think the "what works" section of there is already pretty compelling -- for example, it's an annoyance that "darcs-all diff" produces a diff file which mashes together all the subrepos and can't be applied at the top level. It's another annoyance that "darcs diff" doesn't produce unified diffs by default, what's the point of a diff that can't be |patch-ed? It seems from your discussion that subrepos are intended for your category "the rest of libraries (e.g. filepath, containers, bytestring, editline)" i.e. things that you expect to passively track and occasionally pick up new patches from. What's the argument against using subrepos for those? To me, the major gotcha is "git submodule update" detaching the changes, however changing the default to be a --merge would fix that for me. What about that don't you like? Would you rather want a "git submodule update --just-complain-and-exit"? The last 2 drawbacks you mention (pushing to submodules first and needing to commit to GHC for every subrepo commit) is IMHO the price to pay for a guarantee that you're always able to check out a coherent set of changes. If that's too onerous, maybe some of those libraries just belong in the main GHC repo. I'm another interested bystander who thinks that git would be a step forward, btw.