[Haskell-cafe] Notes from "Haskell takes over the world" BoF at ICFP

[Jason Dagit]

At the risk of starting a darcs vs. git discussion I have some
thoughts about the tension.

On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart <dons at galois.com> wrote:
[snip]
> == GHC ==
>
>  * ghc status
>        + 50% split in room on moving ghc from darcs to git.

I don't see that tension resolving itself easily.  VCS tools are
subject to "network effects".  If your friends are using VCS Foo and
you want to work with them, then you adopt Foo too.  It's also a part
of the toolchain that people tend to have strong opinions about.

One possible way to lessen the tension would be good vcs bridge tools.
 There have been numerous repo converter projects, some even
supporting synchronization.  There is already a git-svn tool.  Maybe
there should be a git-darcs (and a darcs-git)?  If a git hacker out
there wants to add darcs support to git, I'd certainly be willing to
help them get started.

Pushing on this a bit more, I'm fairly convinced that darcs and git
are dual to each other in terms of underlying models.  As such, I have
some ideas on how to unify them/convert between models.
Unfortunately, actually having something to use is very far off as the
ideas themselves are still immature.

As far as I can tell, the main reasons to vote for git:
  * Some people simply love git and want to use it for every project
  * Git is faster and/or more memory efficient for some operations (most? all?)
  * Github

As far as I can tell, the main reasons to vote for darcs:
  * GHC already uses it (inertia)
  * The windows support appears to be more mature (I admit, this is
somewhat subjective as neither has a spotless record here)
  * Key players, such as the Simons, prefer the darcs UI over the git
UI (i.e., some people prefer darcs)
  * Darcs 2.x has consistently improved in robustness and efficiency
over the last several years, continues to improve, and incorporates
ideas from git.  (there is currently an experimental 'rebase' command
in the development branch of darcs)
  * Cherry picking

Note: I didn't mention feature branches as a reason to prefer one over
the other.  Both darcs and git support this.  Git uses in-repo
branches and with darcs you can simply do a local lazy get.  Some
people prefer one mechanism over the other, but the point is they both
support the workflow.  I also didn't mention server side bare repos.
I'm trying to focus on the context of what GHC should use and as Simon
Marlow points out, the current darcs workflow is scaling well so it
seems that the lack of darcs bare repos is not an issue at the moment.

I would like to see the tension of darcs vs git for GHC reduced.  I
think it ultimately amounts to: Contributors need to be able to use
the one they prefer, instead of being forced to use the one GHC devs
use.

Us haskellers could build a tool to solve that problem.

>        + bug reports and interaction load with ghc

I'd love to get elaboration on this point.

>        + well documented workflow for lightweight changes
>        + heavy weight process for major work.
>            + bugs, tickets.
>        + Simon Marlow "contributions are going up, and process is working well"

That's reassuring.  Is their workflow documented for the benefit of
other Haskell projects and the greater FOSS community in general?

Thanks,
Jason