4 ms·

What was it? I used darcs quite a bit back when I used to write more haskell, but have lost touch over the last decade or so. What happened? I was always under

What was it? I used darcs quite a bit back when I used to write more haskell, but have lost touch over the last decade or so. What happened? I was always under the impression that one of the things that set darcs apart was that it had a theoretical basis. Did something go wrong with that?

hobofan 7y ago
Darcs has the problem of exponential merges[0], where certain merges that would have a lot of conflicts takes an exponential amount of time (based on number of conflicts), which in practice can render certain patchsets unmergable. The authors of Pijul[1] found a solution for the exponential merge problem, and from what I've heard there have been discussions that darcs might in the future switch to Pijul's algorithm. [0]: http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr... [1]: https://pijul.org https://pijul.org
- brandmeyer 7y ago
  The irony here is that all of the large git projects I've worked on don't use merges at all. They cherry-pick and/or rebase their patches around.
  - erikpukinskis 7y ago
    Yeah, I never merge. No idea why you would want to.
  - gimboland 7y ago
    Cherry-picks can still lead to conflicts though, no? It's essentially just a particular kind of merge.
    - brandmeyer 7y ago
      My mental model is that cherry-picks are like a copy by-value of one or more patches. A merge is a copy by-reference of a specific series of patches. It just so happens that what I usually want in practice is to make copies by-value. There are other integration workflows that make copies by-reference with dedicated merge commits. But my team's most common use case for long-lived branches is to track bugfixes for deployment to remote hardware separately from mainline development. So, by-value copies of small changes is much more common.
- gimboland 7y ago
  Thanks! Interesting stuff!

hobofan 7y ago

Darcs has the problem of exponential merges[0], where certain merges that would have a lot of conflicts takes an exponential amount of time (based on number of conflicts), which in practice can render certain patchsets unmergable. The authors of Pijul[1] found a solution for the exponential merge problem, and from what I've heard there have been discussions that darcs might in the future switch to Pijul's algorithm. [0]: http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr... [1]: https://pijul.org https://pijul.org

brandmeyer 7y ago
The irony here is that all of the large git projects I've worked on don't use merges at all. They cherry-pick and/or rebase their patches around.
- erikpukinskis 7y ago
  Yeah, I never merge. No idea why you would want to.
- gimboland 7y ago
  Cherry-picks can still lead to conflicts though, no? It's essentially just a particular kind of merge.
  - brandmeyer 7y ago
    My mental model is that cherry-picks are like a copy by-value of one or more patches. A merge is a copy by-reference of a specific series of patches. It just so happens that what I usually want in practice is to make copies by-value. There are other integration workflows that make copies by-reference with dedicated merge commits. But my team's most common use case for long-lived branches is to track bugfixes for deployment to remote hardware separately from mainline development. So, by-value copies of small changes is much more common.
gimboland 7y ago
Thanks! Interesting stuff!