RFC: migrating to git

[Simon Marlow]

On 10/01/2011 13:02, Max Bolingbroke wrote:
> On 10 January 2011 11:19, Simon Marlow<marlowsd at gmail.com>  wrote:
>> Let us know what you think - would this make life
>> harder or easier for you?  Would it make you less likely or more likely to
>> contribute?
>
> Well, as a sometime-contributor I would certainly be happier hacking
> on GHC if it were git based. When working on a GHC branch, it is
> rather irritating to spend time work around the inevitable Darcs bugs
> rather than hacking on the code.
>
> 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.

> 2) There was also concern that Git isn't so great on Windows. I have
> heard that this is less of an issue now, but I never personally
> suffered from any problems, so can't be sure. (FWIW I used Git on
> Windows industrially ~1 year ago for 3 months and didn't have
> problems, though the people around me occasionally had issues with
> e.g. case insensitivity causing obscure error messages).

Again, it would be a prerequisite that all our workflows work on Windows 
too.  We'd have to do some research to check for problems.

> 3) The git transition has the potential to make Ian's workflow (i.e.
> maintaining branches for old GHC releases) harder.
>
> AFAIK currently Ian just "darcs pulls" a particular patch from GHC
> HEAD into e.g. the GHC 7 branch. Darcs automatically works out which
> of the earlier patches are dependent on that patch and deals with
> pulling them in as well (if they are not already present).
>
> If GHC HQ transitioned to Git but committed all patches to master then
> Ian's job might be significantly harder because he would have to use
> "git cherry-pick" to pick out any bug fix patches that should be
> merged back to e.g. GHC 7. Unfortunately, Git does not provide any
> mechanism for automatically working out which earlier patches commits
> on the cherry-picked commit, so this will fail quite often. Ian will
> then have to manually identify the dependents.
>
> To make Ian's life easier GHC HQ could adopt a new workflow. For
> example, bug fixers could fix their bugs on *new* branches (one peg
> bug) which start from the last major GHC release (right now, GHC 7).
> After fixing the bug on that branch, they can then merge the branch
> into master. Now when Ian merges a bugfix to a GHC 7 patchlevel
> release he just needs to merge that bug fixing branch into the ongoing
> GHC 7 branch.
>
> Naturally other workflows are possible and I'm sure other list members
> will chime in with their own favourites :-)

I don't think the dependencies get very deep in most cases, and my 
impression is that we often don't want to pull the dependencies anyway, 
so darcs forces us to merge the patch manually (Ian would be able to say 
for sure how often this happens).

However, if it turned out that we had to change this workflow it 
wouldn't be the end of the world.  Fixing bugs on the stable branch 
rather than HEAD would be a slight inconvenience, but is arguably the 
right thing anyway.

> Has GHC HQ thought about these workflow issues? Are you happy with any
> changes that might be required to your workflows?
>
> Ultimately I'm quite concerned with keeping GHC HQ happy (as you guys
> do the lions share of the work!). I feel we should only make the
> switch if the most frequent committers (i.e. Simon, Simon and Ian) are
> *totally happy* with it and any associated workflow changes that may
> be required.

Speaking for myself, I tend slightly towards making the switch, becuase 
I'm keen to make branching less painful.  However, I think if it were 
just the three of us, there probably wouldn't be enough motivation to 
overcome the cost of switching, but if there is enough interest from the 
rest of the community that might just swing it.

Cheers,
	Simon