What is Reddit's opinion of
darcs?
From 3.5 billion Reddit comments
19 reviews of this app found across Reddit:
Unix is not the last word in OS design.
I don't like the modern trend in language design for ever more restrictive type systems, priviledged/first-class data structures etc. Almost all new programming language developments impose the designer's ideology on the programmer.
The web should primarily be for documents and the desktop for application software.
git has a piss-poor slipshod UI design and the git community responds to this criticism with machismo (I am proficient with git btw). I still use darcs and I think others should consider it too because git can never be as user friendly without completely changing its underlying model. Why do we continue to develop camp? - YouTube
We would all enjoy more innovation (especially in the long term) if we chose the technically best tool for the job rather than just the most popular one. Network effects are a viscious cycle -- more people means more support means more people... The only way to escape is to accept that there will initially be less support in the short term for a maybe newer or older undiscovered gem.
This has always and everywhere been the sacrifice to be made for the sake of innovation.
Really not sure what exactly is different. From a cursory glance I can only see that they give things different names, they call commits patches and call merge-commits conflictors.
edit: Oh, well from their own Differences from Git page it seems like there's not that many differences for end-users. The "linear history only" being the probably most impactful difference.
After a few minutes of research on darcs here are some reasons for not switching:
- ~~Looking at the changelog it seems darcs development has practically stopped since last year.~~ As /u/hsenag points out below: this is the changelog for the stable version so it is not representative of the amount of development.
- darcs doesn't scale well to very large codebases (I got this info from a reddit thread of 6 years ago so it might be outdated; this is also another problem: there isn't a lot of recent information about darcs)
- ~~I wasn't able to find a darcs alternative to github for free hosting and collaboration.~~ As /u/hsenag points out below hub.darcs.net is a good alternative for github.
- I already use git for some projects that I cannot easily switch to darcs.
~~None of these are big problems for small personal projects, so I might use it for that. But those projects are usually so small (< 400 loc) that it doesn't need version control (just making a copy of the file when making major changes is enough for me).~~
~~I am all for encouraging functional programs and improving the haskell ecosystem, but it is pretty essential for me to be able to collaborate. If I can find an alternative to github that I can use with darcs I would start using it immediately.~~
Another advantage to me would be that it is easy for beginners so I can collaborate on projects with non programmers or beginning programmers.
EDIT: I have since I wrote this comment tried darcs and it looks very good. I will seriously consider using darcs for all my future projects.
Did you mean darcs? If so, indeed, being a a distributed version control system, it can be a part of a daily workflow of non-Haskeller; though I wonder if it is actually used to large extent by non-Haskellers to manage their source code.
> Git happened to have taken over the majority of the mindshare. SQLite likely gets a lot of "why don't you use git?" I suspect Linus gets less "Why don't you use darcs?"
That is a little unfair. Both git and fossil are capable of developing sqlite, but at the time git was release (2005-2006), there was no way darcs could have handled the linux codebase and development method. See the darcs faq question: Is the exponential merge problem fixed yet:
> Answer from 2012-08-02 > > No. > > Darcs 2 (introduced in 2008-04) reduces the name of scenarios that will trigger an exponential merge. Repositories created with Darcs 2 should have fewer exponential merges in practice. For older repositories, see Should I convert my repository to the Darcs 2 format?. > > Darcs 2.10 introduces the feature darcs rebase that helps you to avoid situations that trigger an exponential merge. > > Fixing the underlying patch theory problems will potentially take us a very long time, but we are working on it.
Darcs 1 was very slow even for repositories a fraction of the size of linux, so I can't imagine using it with linux and dozens of developers.
Darcs is generally superior when it comes to interface. It sounds implausible at first, but with darcs there exists a VCS that you can use without reading docs.
...things just get hairy when you've got too large repositories. While exponential merges are rare, they still didn't manage to eradicate them completely from the theory. Rebasing, which is about to be released, is a stop-gap for that. Not at all elegant, but better than losing good will in the years it might take to figure out what darcs 3 should look like.
The next step is one that treats the current repo as a collection of patches that may or may not commute applied to the empty repo, makes cherry-picking with patch dependency-tracking the fundamental operation, gets merging right, and has a UI that mere mortals can understand.
darcs is not very popular anymore, because it has a pretty bad performance issue. Pijul is a tool that is also based on a theory of patches, and doesn't have the performance issues but it is still in alpha.
That said right now git is used everywhere and it would be silly to tell a noob to learn anything else instead rather than in addition.
I use darcs because the user experience is still night-and-day better than git's. darcs has had fast-import and fast-export support for some time now, so I don't worry about losing history if I should ever decide to switch. darcs is open source, and builds wonderfully using stack, so I also don't worry about suddenly losing access to darcs, or to the toolchain necessary to build it, should development ever stop on it.
> The -p craze has pretty well blanketed the git universe but hg is just not picking up on it very well.
Well, that might be because it was stolen from darcs record --interactive, which I'm relatively sure was the first to implement it. It's hard to pick up a feature from git you've already stolen wholesale from someone else.
- darcs, distributed version control based on patch theory. it's pretty awesome: http://darcs.net/
- in the past, we've mostly written tests for critical things where failure would be a big problem. sort of a lack of time thing. as of a couple months ago, we're starting to have a lot more test coverage.
- all of the ones we talked to :)
> Hash of previous commit is not included in the next one
?!?!?!?!??!?!?!!?!?!?!?!?!
Hashes of parent commits are definitely included!!!
You can't freely rearrange them. Well, you can rebase, but that changes all commit hashes after the earliest one you touched. i.e. you're technically creating new commits. This is why if you want to change history of a public repo, you have to force push, which is noticed by everyone.
If you had independent "commits", they wouldn't be commits, they'd be patches in a system like darcs or pijul
Darcs is a version control system that is founded on theory of patches. Its theory is elegant and intuitive, and makes merges and conflict resolution quite easy in practice compared to other DVCS. However, it suffers from the exponential merge problem at certain points, which keeps it from large scale use. You can read about the exponential merge problem in the wiki, and if solved, can result in better usability, and has the potential to be used as the basis for other DVCS too.
If you don't like git and want a simple to use version control system, look into darcs. darcs is vastly simpler to work with and you can probably get up to speed in <10 minutes.
Otherwise, like others are saying, you can use git locally without issue. There are even a multitude of github-like webGUIs that you can locally host.
On the darcs model explanation, there are some examples of what can be done with patch-based version control.
Very interesting is, for example, that patches can change with context.
I haven't had a need for git-style branches with darcs because I have spontaneous branches which essentially work like hashtags on twitter -- you can aggregate records (aka commits) with selected hashtags for pull, push, send, log etc..
The title seems to be misleading, importing git repos doesn't appear in this list and is still in progress.
Anyway, darcs is a lovely software. Thank you for developping it.
It did hurt its case. Darcs 2.0 got better, and we're now over 2.8.
Is this exponential merge conflict still is a problem?