RFC: migrating to git

[Brian Bloniarz]

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.