RFC: migrating to git
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Tue Jan 11 05:01:43 CET 2011
I agree with Roman's position. I would prefer to stay with darcs (it has its advantages and disadvantages, but has definitely been improving much in the past).
In any case, all of GHC including all dependencies must be available and patchable with a *single* VCS. Mixing VCS' will lead to madness.
PS: This talk about contributing to a project if it changes its VCS seems a bit lame to me. You contribute to a project in a serious way because you care about the project and because you need whatever improvements you are implementing, not because you like the VCS.
> On 10/01/2011, at 13:27, Simon Marlow wrote:
>> On 10/01/2011 13:02, Max Bolingbroke wrote:
>>> However, I remember the last time this came up there were some issues
>>> that might make migration painful. From the top of my head:
>>> 1) Some people expressed concern that they would have to use two
>>> revision control systems to work on GHC, because not all GHC
>>> dependencies would be git-based.
>> It would be a prerequisite to switching that a GHC developer only has to use one VCS. So we either migrate dependencies to git, or mirror them in GHC-specific git branches.
> I'm not sure how that is going to work. It might well be possible to build GHC using only git. But most GHC developers also contribute to various libraries which are often quite intimately linked to GHC. In particular, GHC patches are often accompanied by library patches. Unless all those libraries switch to git, too, we'll have to use both git and darcs which would be *really* annoying.
> Personally, I rather dislike git, mostly for the reasons that Malcolm already mentioned. Compared to darcs, it seems to get in the way much too often. It also seems to make finding buggy patches rather hard. But maybe I just don't know how to use it properly. In any case, a switch to git wouldn't deter me from contributing to GHC, but neither would a switch to any other VCS. I would certainly swear more often while developing, though.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users