GitHub and GHC

[Edward Z. Yang]

For me, at least, Github is a convenient way to share commits between machines
that I do development on, without needing to spend X megabytes for the whole
repository history (since Github can share objects across forked repositories:
that's why forks count much less against your space limit).  If you keep your
branches tracking GHC HEAD at a reasonable pace, it's a workable arrangement.

Cheers,
Edward

Excerpts from Manuel M T Chakravarty's message of Sun Apr 10 09:08:17 -0400 2011:
> Simon Marlow:
> > On 09/04/11 10:11, Edward Z. Yang wrote:
> >> Excerpts from Manuel M T Chakravarty's message of Sat Apr 09 01:56:43 -0400 2011:
> >>> Would the use of submodules, instead of separate repos and the sync-all
> >>> script, address that problem, so that forking the main repo would also fork
> >>> the submodules?
> >> 
> >> Submodules would definitely help, and it's something we should consider long
> >> term.
> > 
> > Agreed.  I spent a while evaluating submodules, and I wasn't convinced enough that the current support for submodules in git was quite ready, there seemed to be some rough edges, and I managed to get my repo into a confusing state a few times.  There are also more steps involved in the workflow when you have submodules, and hence more ways for us to trip up.
> > 
> > Let's get our workflow settled with plain repos first, and then reevaluate submodules at some point in the future.
> 
> This still leaves the question of whether forking on GitHub makes sense given the current arrangement.  If not, that would seem to be a strong reason to look for some better setup.
> 
> Manuel