RFC: migrating to git

[Max Bolingbroke]

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.

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).

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 :-)

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.

Cheers,
Max