RFC: migrating to git
roconnor at theorem.ca
roconnor at theorem.ca
Tue Jan 11 01:36:14 CET 2011
On Mon, 10 Jan 2011, Simon Marlow wrote:
> It's time to consider again whether we should migrate GHC development from
> darcs to (probably) git.
>
> From our perspective at GHC HQ, the biggest problem that we would hope to
> solve by switching is that darcs makes branching and merging very difficult
> for us.
I don't develop GHC so you shouldn't really listen to me, but if you think
Darcs makes branching and merging very diffcult then you won't like Git et
al. which make braching and merging impossible since their semantic model
is broken.
One of the main tasks of a distrubuted revision control system is to
handle branching and merging, so you'd think they'd get that core
functionality right. But almost every distributed revision control system
fails to satisfy the merge law which states:
Merging a the change from branch B into branch A followed by merging a
subsequent change from branch B into branch A will have the same results
as merging both changes from branch B into branch A at once.
So if your histroy looks like
A
| \
B1 C
|
B2
then the result, C2, of merging B1 into C and then merging B2 into that
A
| \
B1 C
| \|
B2 C1
\|
C2
should be equal to the result, C3, of merging B2 into C
A
| \
B1 C
| |
B2 |
\|
C3
Git and basically every other DVCS fails to statify this law. See
<http://web.archive.org/web/20070603113858/zooko.com/badmerge/simple.html>
for an example where Git will fail to satify the merege law (granted I
haven't tested Git on this example lately). AFAIK th only DVCSs that
statify this law are Darcs and Codeville.
Remember what Dijkstra said, "People willing to trade correctness for
speed deserve neither and will lose both", or something like that.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
More information about the Glasgow-haskell-users
mailing list