Simon Marlow:

> On 10/04/2011 14:08, Manuel M T Chakravarty wrote:
>> 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.
> 
> I think it makes sense for the limited case where you only need to fork one 
> of the repos.  That's not enough for development that spans multiple repos, 
> but in many cases it's sufficient (most of my branches only touch one repo, 
> for example).

May be hacking on DPH is somewhat unusual in that it almost always involves 
multiple repos, but my experience even with GHC repo only changes is that the 
build breaks after a while if you don't either frequently merge from the HEAD 
(which I personally dislike) or fork all repos.

> While it would be really nice to have an easy way to create public forks for 
> the whole GHC tree, we didn't have that with darcs either, so we haven't lost 
> anything.  In due course we can look into submodules or other ways of 
> achieving this.

Sure, nothing is lost, but it be nice to offset the hassle of switching.  
GitHub is to me one of the most attractive aspects of Git.  Are there any other 
ways of achieving this?

Manuel


_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to