Why darcs instead of git? [closed]

Question

Using pure functional languages can have a lot of benefits over using impure imperatives, but low level systems languages will generally allow you to achieve much greater performance, especially when they are imperative because it allows you to specify the exact steps in how the cpu should compute the result.

If there is ever list of tools where high performance is an absolute must then I would put VCS at the top of that list, and git achieves this very well. However performance is not git's only advantage over many other other types of version control systems anyway.

The git team is handling the unsafe c code very well, and I never worry about my type system (or any other features of the language it is written in), so why is it that there is a lot of haskell developers that must use darcs when they will only be using the finished product?

Blench

indeed why? have you actually seen people move from git to darcs? – Desiccator

@Desiccator j: https://mcmap.net/q/450863/-convert-git-repo-to-darcs :-) – Entrails

This whole question is nonsense. Tuned Haskell performs just as quickly as tuned C. And is easier to write, debug, and maintain. Darcs is slower than git because it uses a richer model and requires slower algorithms. This translate to an experience where you query darcs, as opposed to "programming" git at the command line. – Timothy

I have discovered this question after working with Git since 2008 -- lately a stubborn thought keeps re-appearing in my head every time I need to use Git with a large(r) project -- that I haven't become a fan of its snapshot-based model. I suspect I brush Git "against the fur" so to speak, the more so it insists on its snapshot-centric workflow, but I have to admit that even for projects that didn't prompt me to think of patches and alternative VCS to try out, I now instinctively think of patches and patch sets and how I could combine them -- but not easily can with Git. – Boxberry

Answer 1

I think in general certain communities of users will gravitate towards one technology or another. This is especially true if a technology uses the community's language. It is also possible(though I have no idea) that the author and/or initial users of Darcs were fairly well known Haskell developers, thus having more influence.

There are other examples, such as Mercurial appears to be more popular in the python community while other languages appear to use Git.

Once you are using a particular piece of software it may not be worth it to switch to another even if there are advantages.

Honestly though use whatever you like best. At this point it is almost a requirement to have hg, git, and svn installed and know the basics to using them. If you are using Haskell it appears you probably need to add Darcs to this list.

Constituency

Answer 2

Darcs manages collections of patches instead of chronological history. More about this is on the darcs wiki page documenting differences with Git. This difference is illustrated by a darcs ability to pull patches interactively, out of order. For example, you could pull all patches with a commit title that matched a ticket number from "development" to "testing". Darcs would automatically make sure any other patches these patches depended on were pulled as well. With this key feature, you may need far fewer branches and repos to maintain. While in Git it's very helpful to create a branch before doing work, in Darcs that's often not a concern, as long as you your related commits mention the same ticket number. I used a workflow based on this extensively with a 100,000k LoC project. Besides that technical difference, darcs is very user-friendly. There are fewer commands, and most are interactive by default, prompting you about what to do.

Because of darcs’s strengths and ease of use, I much prefer it over git, which I also use regularly for open source projects. Darcs is easy enough to use that even if you have to learn git to contribute to some projects, you may still enjoy and benefit from using darcs on other projects where you have a choice.

Donative

6 years later, Git is a given for any project I do with collaboration. Git's storage model helps it with performance, but I still wish someone would build more of Darc's UI on top of Git's storage model. The Darcs UI would be easier for new users to learn. – Donative

This "dynamic branch creation" doesn't make sense to me, given that it allows you to create code bases that were never meant to work – Ligetti

@MarkStosberg so the storage model outweighs the benefits of the branchless model? – Pantisocracy

@MarkStosberg What about github.com/ganwell/git-darcs — using git as a collaboration “backend” but darcs as the UI “front end”. – Pantisocracy