This. Surely git "has won", but you'd be fitted with a pretty bad sense of history if you think that this is forever. Thus, it definitely does not hurt to keep Darcs in view.

I bet that if any version control system is going to replace git, it'll look at least as much like Darcs as anything else.

I'm no expert by a long shot, but to me it appears that if we're going to try to finally make version control user-friendly, something inspired by Darcs' patch algebra may well be at the base of it. While Darcs is impractical for a whole set of use cases, it's very practical for a whole other set of use cases.

It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. Just a better theoretical base for some edge cases is not enough.

Hg has also quite some mindshare. I consider it the only DVCS, which still seriously competes with Git. Apart from that, there are niche groups: Haskell with Darcs, Ubuntu with Bazaar.

Fwiw he didn't say Darcs will replace git, he said that whatever eventually replaces git will likely implement some of Darcs best features like the patch algebra.

Hence, it's worth taking a little time to actually understand those features, even if you never use darcs. Plus the mental exercise and learning something new is valuable in and of itself.

> Just a better theoretical base for some edge cases is not enough.

That's why I said "user friendliness". Even on a superficial level, Git is enormously lacking in this aspect. More fundamentally, the way moving changes around between branches works in Darcs is significantly simpler and "hey, it read my mind!" than in Git, where you need to understand the underlying object model and the tools very well to do this well. Sure, many other things are a disaster in Darcs, but I'm not saying Darcs will replace Git. I'm saying something inspired by it well.

> It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it.

People said this about Subversion not so long ago.

> By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc

I think it is good to periodically evaluate the tools used. And initially there was quite a bit of excitement around DVCS and everyone was playing with them (including me). Me and most have settled on one tool (git). And actually this was not my preferred tool of choice, I like Bazaar, but 2 things happened: 1) Bazaar has not won the popular vote (so chances are on a new team I would have to learn git anyway) and 2) DVCS as a technology has stopped being new and exciting.

For example at some point OO features and garbage collection was exciting and new. Now they are just another tool in the shed available for use and as I said, this area of tech for me has lost the "wow" factor.

I also realized I have a limited bandwidth both to learn and to remember things. I would rather devote this bandwidth to learn new languages or other technologies (databases) rather then learn more DVC systems.

If you're looking for another "wow" factor in programming languages, the following links may interest you: http://www.tinlizzie.org/ometa/ http://piumarta.com/software/maru/ http://vpri.org/html/work/ifnct.htm and of course http://www.vpri.org/pdf/tr2011004_steps11.pdf

Their way of doing things seems to require a 1000 times less code than current mainstream techniques. They can do a whole language stack in less than 2000 lines of self-implementing code for instance (not super-optimized, but fast enough). Compare with GCC or GHC. Even Lua is bigger.

Thank you! Maru and Ometa look interesting.

Speaking of terseness, reminds me of Prolog. I remember thinking how beautiful the solutions are but how broken my brain is as I couldn't come up with them on my own. I could see the final result that someone else produced and understand it, but struggle for hours and hours myself.

I think at some point levels of meta and abstractions can go that high that only very few smart individuals can effectively create products, others more or less hit a wall.

While "the rest of us" could hit a wall at creating such code, we may well be able to modify it. I've seen some Nile code for the graphic stack of the STEPS project, and what startled me was the sheer clarity of it. Syntax and semantics seemed just obvious.

When the teacher is a genius, the student needs not be bright.

It's just being cognizant that VC software has positive network externalities. If you want to play with stuff, sure, go ahead, but if vc systems are just part of your toolset, then git has probably won. I'm in the latter camp: I want something solid and dependable - I'd rather spend my experimentation time with a new programming language or something else.