4 ms·

An easy dismissal without any solid arguments. First, saying "Darcs is slow and Pijul…" is strange, since Darcs and Pijul aim at solving the same problems. The

An easy dismissal without any solid arguments. First, saying "Darcs is slow and Pijul…" is strange, since Darcs and Pijul aim at solving the same problems. Then, Darcs has never been slow for me, I've been using it for about 15 years, I can remember of one minor performance issue. It doesn't scale well to very large projects, but there are extremely few of them. Since concrete arguments are important when discussing with others, the main event which started Darcs' decline was its inability to handle conflicts in GHC (the Haskell compiler), which was at the time the open source project with the largest history (as measured in number of patches). As for Pijul, I'm curious where you got your information from. I know Pijul's authors well, at least enough to know that they are well aware of the algorithms used in Git. Pijul does solve a number of problems: - I know at least one very large-scale project where collaborators are well aware that 3-way merge can mess with their code in really bad ways, and complain about wasting tons of time with that. Unfortunately, I can't embarrass the project's authors by sharing their name, but I can say that it is a widely used piece of software with a really long history. - Knowing that the code you review is the code you merge is the only thing you should care about if you care about your code at all. This is not what 3-way merge gives you, as the Pijul manual clearly explains (see "lack of associativity"). - Patch commutation is what Git tries to do all the time (rebase, merge, rerere…), except with bad hacks which fail in the more complex situations, which is where we need them the most.

TeeMassive 5y ago
Creating patches out of commits and commits out of patches is trivial in Git. I don't see what patch based systems bring more except more complicated algorithms. In the end I want to checkout revisions. Maybe they are equivalent is some respects, but then Git works, is fast and is widely supported by various tools and extensions and if you take one or two hours to learn the documentation is actually intuitive.
- pmeunier 5y ago
  First, congrats for replying to a comment asking you for concrete arguments without using any of those, nor replying directly to anything that was said. Then, I don't think you actually understand what we mean by patches: for anyone who has looked into the topic, patches are obviously not equivalent to commits except in the most basic cases (where all tools "work", in your own terms). A datastructure is defined only with respect to the operations you define on it, I'm sure you use other commands than checkout. For example, people who review snapshots rather than patches before a merge (or even a commit!) either have really small projects, or way too many man-hours to spend. > if you take one or two hours to learn the documentation is actually intuitive Git isn't "intuitive" at all for anything but the most basic operations (I agree it is easy for those, if you are willing to work with snapshots). For example, the existence of `git rerere` clearly shows that Git doesn't model conflicts at all. Then, merges are not unique, Git chooses one at random when there are more than one. Rebase is a horrible hack, "replaying" commits doesn't even always work. Moreover, saying Git is easy isn't a very effective way to show off on HN: if you feel you have to defend Git so strongly, even though it wasn't actually attacked, and to the point of refusing to reply directly to any rational argument, it clearly shows you invested enough time in Git to feel you would lose something if you had to move to a better solution. So, sorry, but I don't think it was just "one or two hours" for you.

TeeMassive 5y ago

Creating patches out of commits and commits out of patches is trivial in Git. I don't see what patch based systems bring more except more complicated algorithms. In the end I want to checkout revisions. Maybe they are equivalent is some respects, but then Git works, is fast and is widely supported by various tools and extensions and if you take one or two hours to learn the documentation is actually intuitive.

pmeunier 5y ago
First, congrats for replying to a comment asking you for concrete arguments without using any of those, nor replying directly to anything that was said. Then, I don't think you actually understand what we mean by patches: for anyone who has looked into the topic, patches are obviously not equivalent to commits except in the most basic cases (where all tools "work", in your own terms). A datastructure is defined only with respect to the operations you define on it, I'm sure you use other commands than checkout. For example, people who review snapshots rather than patches before a merge (or even a commit!) either have really small projects, or way too many man-hours to spend. > if you take one or two hours to learn the documentation is actually intuitive Git isn't "intuitive" at all for anything but the most basic operations (I agree it is easy for those, if you are willing to work with snapshots). For example, the existence of `git rerere` clearly shows that Git doesn't model conflicts at all. Then, merges are not unique, Git chooses one at random when there are more than one. Rebase is a horrible hack, "replaying" commits doesn't even always work. Moreover, saying Git is easy isn't a very effective way to show off on HN: if you feel you have to defend Git so strongly, even though it wasn't actually attacked, and to the point of refusing to reply directly to any rational argument, it clearly shows you invested enough time in Git to feel you would lose something if you had to move to a better solution. So, sorry, but I don't think it was just "one or two hours" for you.