RFC: migrating to git

[Simon Marlow]

On 11/01/11 21:57, Roman Leshchinskiy wrote:
> On 11/01/2011, at 21:41, Iavor Diatchki wrote:
>
>> If GHC and the libraries on which it depends were in git (migrated,
>> or mirrored), then we could use git sub-modules to track the
>> dependencies between changes to GHC and changes to the libraries.
>>
>> Roughly, the workflow would be like this: 1. Make a change to the
>> library and commit it. 2. Make a change to GHC. 3. Make a GHC
>> commit which records the change and the dependency on the commit in
>> the library repository.
>
> What about dependencies which go the other way? Actually, the
> dependency is often mutual: the GHC change won't work without the
> library change and the library change won't work without the GHC
> change. Does git support this?

As I understand it, the GHC repo would specify the required version of 
the library repo.  Right now with darcs we don't get to do this, so if 
you want to back out the GHC tree to a previous state, it's impossible 
to back the libraries up to the right point too (I've found this quite 
annoying when tracking down regressions in the past).

With submodules, when you make a combined GHC/library change, the 
relationship between the two changes would be recorded in the GHC repo, 
which is exactly what you want.

>> This is useful because when someone gets the changes to GHC, they
>> would know that they need to update their library as well (and
>> there is tool support to make all updates automatically). This kind
>> of dependency is not at all obvious with our current workflow.
>
> IMO, darcs-all works pretty well. I don't think I ever really had
> problems with missing library patches.

I often see problems where someone has done 'darcs pull' rather than 
'./darcs-all pull' and ended up with a weird compilation error as a 
result.  If we could eliminate this source of errors, it would be a 
major win.

If submodules actually work for what we want to do, this would be a good 
reason to move to git, I think.

>> The same method works for going back to a previous state of the
>> project, where one can "rewind" the libraries to their old versions
>> too.
>
> This would be useful. Unfortunately, git's rewinding seems rather
> crippled compared to darcs.

In what way?

Cheers,
	Simon

BTW, I just translated the GHC darcs repo into git using 
darcs-fastconvert (cabal install darcs-fastconvert).  It took less than 
10 minutes and seems to have done the right thing.  I'll try to put this 
up tomorrow for people to play with.