On 13/01/2011 19:11, Brian Bloniarz wrote:
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?
I think we'd want it to be all-or-none, i.e. use subrepos consistently
or not at all. Some of these subrepos are developed quite actively and
concurrently with GHC, particularly base. Indeed if it were the case
that we were just consumers of an upstream repo, then I would agree with
you that subrepos are a clear win.
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"?
--merge might be good sometimes, but other times you might want
--rebase, or indeed --complain (which isn't provided, what you get is
--hide-my-changes-and-detach-my-head, which incidentally is an
aptly-named concept).
With sync-all we're getting --merge by default, and you can ask for
--rebase, but we're not getting the head-detaching.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
