4 ms·

Anyone who's ever used Darcs [1] knows that you can do a lot better than Git! So does anyone who's ever used Mercurial, for that matter. Darcs failed to reach

Anyone who's ever used Darcs [1] knows that you can do a lot better than Git! So does anyone who's ever used Mercurial, for that matter. Darcs failed to reach mass adoption, and lost against Git back in the mid-2000s, which for me, at the time, felt like a big step backwards (and in other ways a step forward, since Darcs had some icky bugs and performance issues). Some 15 years later it's amazing that we are still stuck with Git. What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Darcs' equivalent to "git cherry-pick" simply pulls along with it any commits that your cherry-pick depend on. Darcs had flaws that prevented it from succeeding, and the fact that it was written in Haskell didn't help attracting developers. Darcs' philosophy lives on in Pijul, which also looks promising, but unfortunately seems doomed to the same fate of remaining a niche tool. Git ate the world thanks to GitHub, and the next VCS needs a similar kind of killer app that justifies the switch. [1] https://en.wikipedia.org/wiki/Darcs https://en.wikipedia.org/wiki/Darcs

gnufx 6y ago
Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG
- atombender 6y ago
  Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.
  - bb88 6y ago
    > For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. To be fair though, it's a source tracker which are usually small-ish text files. It's not really meant to be a Digital Asset Manager, say. Git can do a shallow clone as well for very large repos. Much of that deep information becomes probably useless over time, unless you're doing code archaeology.
    - atombender 6y ago
      Well, the thread is about what comes after Git. If you ask me how Git could be improved, then what it's "meant" for doesn't matter if there are unsolved use cases. Also, there's no particular reason Git couldn't be modified to work well with large files.
      - bb88 6y ago
        > Git couldn't be modified to work well with large files. Apologies for the late response. Yes. I absolutely agree with that. The trick though is that when changes happen to a large file, what's the best way to do a diff? What if it's bzip2 or encrypted? The other issue is that stagnant large files in your history need to be pruned. I'm not sure how to do that in git right now other than rewrite history.
hibbelig 6y ago
Pijul is the spiritual successor to darcs I think.
rualca 6y ago
> What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Is that property relevant, though? I mean, although it does not need commits to be sequential, well... They already are, and there is no way around that. And sharing commits across branches, whether it's in the form of cherry-picked commits or pure old diff/patch workflows, is something that Git already handles. Additionally, is there any workflow that does require any of those properties/features? Meanwhile, how about Darcs' computational cost?
- atombender 6y ago
  It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. With Darcs, all merging can be thought of as rebasing, except histories remain compatible and mergeable. With Git, on the other hand, rebasing the same commits multiple times result in the same conflicts that need to be fixed every time, which is why "rerere" exists. Darcs does not need "rebase" or "rerere" or any of the other tools for complicated history surgery. As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (exhibit A: hundreds of HN posts about learning to use Git) and is especially daunting for beginners, compared to easier tools like Subversion and Mercurial that provide nicer UIs. Darcs brings modern version control to users without incurring the complexities of Git. It's not perfect — it had/has corner cases where merging became computationally expensive, though I hear there are new developments to fix this — which is why I said the future isn't Darcs.
  - rualca 6y ago
    > It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. That's the part I don't get from your argument. Git has rebase. It works. So where exactly do you see the value added by Darcs? I mean, it's not as if users can only merge or rebase if they use Darcs, right? > As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (...) No, there isn't. In fact, that statement is patently false. git is the simplest and most straight-forward version control system I ever used. Things just work out of the box, they work well, and they work exceptionally fast. Branching is free, merging is free, tagging is free, it's trivial to checkout, it's trivial to setup a shared remote repository, and it's even trivial to setup a remote repo on a USB pen. You don't need to install servers to get it to work locally or remotely, you don't need to bother with extensions to get basic functionality working, and you don't need to use absurd ad-hoc patterns to get basic features such as branching. So is there actually any objective point that can be made in favour of Darcs? I mean, being fast and usable surely is not it. So, what real-world value does Darcs offer?
bb88 6y ago
> So does anyone who's ever used Mercurial, for that matter. So I've used mercurial and git in production. The one thing that turned me off on mercurial was that branching information was stored as part of the commit. This led sometimes to weird conflicts where the branch list needed to be merged. Granted that's been several years ago, so it might be different now, I don't know, and with git I have no need to. I definitely appreciate branching data being meta data outside of the branch. Also Darcs had severe issues maybe a decade ago where merging would appear to cause infinite locking. It wasn't a coding bug, it was due to their originally flawed theory of patches. So while it may be awesome, the world has definitely moved on. It's worth reading this from pijul: > Did you solve the “exponential merge problem” darcs has? > Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future. So good, but polynomial time can still be large beasts computationally.
- pmeunier 6y ago
  Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.
  - bb88 6y ago
    I was worried it was larger than n^2. Thanks for clarifying.
- iggldiggl 6y ago
  I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too. Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.

gnufx 6y ago

Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG

atombender 6y ago
Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.
- bb88 6y ago
  > For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. To be fair though, it's a source tracker which are usually small-ish text files. It's not really meant to be a Digital Asset Manager, say. Git can do a shallow clone as well for very large repos. Much of that deep information becomes probably useless over time, unless you're doing code archaeology.
  - atombender 6y ago
    Well, the thread is about what comes after Git. If you ask me how Git could be improved, then what it's "meant" for doesn't matter if there are unsolved use cases. Also, there's no particular reason Git couldn't be modified to work well with large files.
    - bb88 6y ago
      > Git couldn't be modified to work well with large files. Apologies for the late response. Yes. I absolutely agree with that. The trick though is that when changes happen to a large file, what's the best way to do a diff? What if it's bzip2 or encrypted? The other issue is that stagnant large files in your history need to be pruned. I'm not sure how to do that in git right now other than rewrite history.

hibbelig 6y ago

Pijul is the spiritual successor to darcs I think.

rualca 6y ago

> What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Is that property relevant, though? I mean, although it does not need commits to be sequential, well... They already are, and there is no way around that. And sharing commits across branches, whether it's in the form of cherry-picked commits or pure old diff/patch workflows, is something that Git already handles. Additionally, is there any workflow that does require any of those properties/features? Meanwhile, how about Darcs' computational cost?

atombender 6y ago
It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. With Darcs, all merging can be thought of as rebasing, except histories remain compatible and mergeable. With Git, on the other hand, rebasing the same commits multiple times result in the same conflicts that need to be fixed every time, which is why "rerere" exists. Darcs does not need "rebase" or "rerere" or any of the other tools for complicated history surgery. As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (exhibit A: hundreds of HN posts about learning to use Git) and is especially daunting for beginners, compared to easier tools like Subversion and Mercurial that provide nicer UIs. Darcs brings modern version control to users without incurring the complexities of Git. It's not perfect — it had/has corner cases where merging became computationally expensive, though I hear there are new developments to fix this — which is why I said the future isn't Darcs.
- rualca 6y ago
  > It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't. That's the part I don't get from your argument. Git has rebase. It works. So where exactly do you see the value added by Darcs? I mean, it's not as if users can only merge or rebase if they use Darcs, right? > As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (...) No, there isn't. In fact, that statement is patently false. git is the simplest and most straight-forward version control system I ever used. Things just work out of the box, they work well, and they work exceptionally fast. Branching is free, merging is free, tagging is free, it's trivial to checkout, it's trivial to setup a shared remote repository, and it's even trivial to setup a remote repo on a USB pen. You don't need to install servers to get it to work locally or remotely, you don't need to bother with extensions to get basic functionality working, and you don't need to use absurd ad-hoc patterns to get basic features such as branching. So is there actually any objective point that can be made in favour of Darcs? I mean, being fast and usable surely is not it. So, what real-world value does Darcs offer?

bb88 6y ago

> So does anyone who's ever used Mercurial, for that matter. So I've used mercurial and git in production. The one thing that turned me off on mercurial was that branching information was stored as part of the commit. This led sometimes to weird conflicts where the branch list needed to be merged. Granted that's been several years ago, so it might be different now, I don't know, and with git I have no need to. I definitely appreciate branching data being meta data outside of the branch. Also Darcs had severe issues maybe a decade ago where merging would appear to cause infinite locking. It wasn't a coding bug, it was due to their originally flawed theory of patches. So while it may be awesome, the world has definitely moved on. It's worth reading this from pijul: > Did you solve the “exponential merge problem” darcs has? > Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future. So good, but polynomial time can still be large beasts computationally.

pmeunier 6y ago
Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.
- bb88 6y ago
  I was worried it was larger than n^2. Thanks for clarifying.
iggldiggl 6y ago
I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too. Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.