Version control systems

Manuel M T Chakravarty chak at
Sun Aug 10 00:40:27 EDT 2008

Ian Lynagh:
> On Sat, Aug 09, 2008 at 03:46:50PM +1000, Manuel M T Chakravarty  
> wrote:
>> I am not talking about all libs, I am talking about the core libs.
>> Most developers of the core libs are also GHC developers.
> I'm not sure that's true. e.g. Malcolm and Ross both commit to the
> bootlibs, and we get a lot of patches from various people in the
> community.

Ross does commit patches to ghc (according to darcs changes).  So,  
either he stops that or has to learn git anyway.

I don't think we are talking about random contributions from the  
community.  If anything, we need to compare two numbers

(1) developers who need to start using git when the ghc repo changes and
(2) library developers (ie, people with commit bits regularly  
contributing to the boot libs) who do not contribute to ghc and hence  
could avoid learning git if the boot libs stay in a darcs repo.

>> I *strongly* object to moving to git before this isn't sorted out.
> FWIW, personally I would prefer staying with darcs. I prefer its
> underlying philosophy, and I find its UI far more intuitive and easy  
> to
> use.

Personally, I am more than happy to stay with darcs, too, but my  
understanding was that at least the Simons decided that we are going  
to move from darcs to git.  All I am saying is that whatever vcs ghc  
uses, you need to be able to *easily* get, modify, and commit patches  
to the HEAD and the boot libs with *just one* vcs.  Using two vcs is  
going to make the current situation worse, not better.

For example, SimonPJ said one reason for switching vcs is that interns  
had trouble getting started because they did have trouble obtaining  
the head as darcs caused them grief.  If the boot libs stay under  
darcs control.  Nothing is one, the same interns still won't get going  
any quicker.  Presumably, they are going to take even longer, because  
they can now get into trouble with darcs and git.

We want to lower the barrier to entry, not raise it.  By effectively  
adding a complications (namely git) and not removing any, matters will  
get worse.


More information about the Glasgow-haskell-users mailing list