(λblog. blog blog) (λblog. blog blog)

diverging since 2008

Darcs vs. Git

2008-12-18 23:50

I'm not sure whether it's actually worthwile to pollute the internets with yet another VCS rant but here goes...


Pearls of wisdom on #haskell:

<int-e> Saizan: what advantage does darcs have, over git, for purposes of tracking the history of a wiki? darcs is all about ignoring the history.

Disregarding the wiki context (comment from a discussion about gitit, a haskell wiki engine that uses git as a storage backend), this quote sums up exactly what has been my problem with darcs. Background: I use darcs for managing my config files and for small one-man projects but for everything bigger I just fall back to git.

I'm irked by having to have a separate working copy for each branch. Firstly, this sucks because pushing all branches to a public repo needs additional effort. Also, combined with not-caring-about-history this makes forking from the past or tagging a past revision very ugly. I want my VCS to store everything and not force me to bookkeep on branches. Darcs takes branches back to the SVN age.

Git can be adapted to any sort of workflow and it'll mostly do the right thing. Darcs doesn't have any thing to adapt, and instead of doing the right thing it does nothing on most issues. I appreciate the minimalism, but just don't like the way darcs forces me to act with a large project.


Interface-wise, I love the interactive approach of darcs, but git is getting close with those -i flags. rebase -i is great for cleaning up history, commit -i and add -i are almost as nice as darcs's record. gitk is an essential tool for the non-linear development style git encourages (and darcs discourages IMO). After the initial learning curve, git is a great and consistent tool.

Tags: conf.