Version control systems

Malcolm Wallace Malcolm.Wallace at
Sat Aug 9 16:30:52 EDT 2008

>>>> I seriously hope the plan is to move all *core* libraries  
>>>> (including
>>>> GHC's cabal repo) etc over to git, too.

>    * one build system
>    * one vcs
> This is a chance to make a big step towards accessibility, let's  
> make that step.

Ultimately, I don't think git would make ghc any more accessible to  
new contributors.  Darcs is not especially offputting to any beginner  
who already knows something about VCS in general.

What the move to git is about, is making life easier for the  
*existing* HQ and core contributors.  Evaluate it on that basis, and  
not in terms of unknown (and unknowable) benefits to current non- 
contributors.  Indeed, you should also consider how many contributors  
you might lose in a move.

I do hear some significant current contributors having doubts. I can  
certainly appreciate that having to run 2 VCS in parallel might be  
confusing and simply make matters worse than at present.

The libraries question is a difficult one.  We have made a lot of  
effort over the last 5 years to build infrastructure and code that is  
shared and portable across multiple implementations of the language.   
Is this the time to fork those supposedly "common" core libraries into  
ghc versions vs the rest?

As someone who is not a contributor to GHC, and has never experienced  
anything more than trivial problems with darcs, I have not felt  
qualified to comment on the proposal to change GHC's VCS.  But as a  
frequent fixer of breakage in the core libraries, I would be reluctant  
to have to move to a different VCS there.  If the core libraries do  
move, it will be increasingly difficult to avoid also needing to move  
nhc98 and Hugs and goodness-knows how many other libraries.  For me,  
it would be un-forced, annoying, and I may not have the extra time  
available to keep up.

So there is a danger that the community will be left with a single  
(albeit very high quality) compiler, with no need for a Haskell Prime  
(or any other Standard) in future.

If there are technical solutions that can reduce the pain, whilst  
keeping multiple stake-holders happy, then I think they should be  


More information about the Glasgow-haskell-users mailing list