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).
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.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
