RFC: migrating to git
marlowsd at gmail.com
Fri Jan 14 10:11:36 CET 2011
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:
> 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
With sync-all we're getting --merge by default, and you can ask for
--rebase, but we're not getting the head-detaching.
More information about the Glasgow-haskell-users