4 ms·

Compared to git, it relies on patches rather than a branch approach. I think it's more intuitive. Less opportunities to do silly things and some things that ar

• rumanator 7y ago
  > Compared to git, it relies on patches rather than a branch approach. Is this even relevant at all? I mean, in the user's POV the role of a VCS is to CRUD changesets and branches. As long as the user can commit their changesets and audit the DAG of past commits, who cares how the system is implemented under the hood?
  • pmeunier 7y ago
    > in the user's POV the role of a VCS is to CRUD changesets and branches That would be the role of a filesystem, and Git is a perfect distributed filesystem. A VCS also allows people to merge their changes and to detect and handle conflicts gracefully. > who cares how the system is implemented under the hood? Pijul is not at all about the underlying implementation of commits. Patch commutation is a radically different way of thinking about cooperation, and (1) much simpler and (2) has the potential to scale to much much larger repositories.
    • rumanator 7y ago
      > That would be the role of a filesystem No, the role of the file system is not to track how changesets are organiced into branches. That's the responsibility of a VCS like Git or Mercurial or Pijul. The VCS is the interface and whatever it does with the file system is an implementation detail that's abstracted away by the VCS's interface. Similarly, patches are only relevant as an external interface of the VCS, and one that users have no good reason to use.
      • pmeunier 7y ago
        > No, the role of the file system is not to track how changesets are organiced into branches. Oops, we just got a little bit more feature requests for a VCS than "CRUD changesets and files". But this isn't an answer to my feature request, which was the ability to merge changes. > Similarly, patches are only relevant as an external interface of the VCS Why? If they're relevant as the external interface, maybe this means they model the problem better than snapshots, and should therefore be used as the implementation.
  • aseipp 7y ago
    Because a thing that programmers tend to call "design" directly impacts how a user is able to interact with the tooling, obviously? Are you seriously asking "How could a thing like 'core design of the system' ever impact how someone uses it?" or are you just trolling for the sake of it? As a real example, I used to be the maintainer of a major project that had long running stable branches. This means I needed to often cherry pick bugfixes from one place to another, but cherry picks are often difficult because they can rely on prior changes you haven't yet picked. In a system like Git, you have to cherry pick things in chronological order in order to replicate each "snapshot" of the history that the original changes came from, so the merge algorithm can figure it out. What change do you start from? Who knows! You have to find the first change that can be merged properly, or by hand, and work your way from there. You effectively have to hold the hand of the tool in cases like this. In systems like Darcs or Pijul, that does not happen. They are always able to keep track of dependencies between patches, and so a "cherry pick" naturally implies picking change A, and all dependencies of A that are not yet available. There is no notion of having to run multiple commands or whatever; it's completely transparent. From there you can either A) accept the dependent changes or B) do surgery, for example, if you need to more carefully backport things. A) is the common case in the vast majority of uses, in my experience. Where as in Git, after a long enough time, almost any uses of 'cherry pick' will immediately fail and require you to start digging and picking out historical changes -- in Darcs, it will keep working just fine, even for dozens or a hundred dependent changes you need. The default features of the tool and their UX matter a lot, here. If you not only can't understand how different core design choices -- like the ones in Pijul or Darcs -- can impact how a user uses a tool, but even refuse to admit that a tool could ever be used any other way: that alone is a great indictment of Git's complete and total monoculture, and precisely why these tools need to keep existing. Then again, computer programmers love having stockholm syndrome and hate reading things, so maybe it doesn't matter. Here is a good, short video explaining the theoretical underpinning of Darcs and how they impact the user (and an old side project, "Camp", that was planned to eventually become Darcs 3). It's over a decade old and just as relevant as it ever was: https://www.youtube.com/watch?v=iOGmwA5yBn0 https://www.youtube.com/watch?v=iOGmwA5yBn0
    • atq2119 7y ago
      On cherry-pick dependencies: there is no way that any VCS can solve that problem for you, because dependencies can be (and often are, for the projects I've worked on) non-local. That is, you can have a dependency even though the changes appear to be unrelated from a textual point of view. I'm all for developing better tooling for digging into blame-history, which is more generally useful and would cover the textual dependencies between changes, but you shouldn't believe that that solves the dependency problem.
  • qznc 7y ago
    > the role of a VCS is to CRUD changesets and branches Then git is wrong and pijul is right for you. :) Gits internal model is to CRUD snapshots and their relation. It would be fine if the UI would hide that but it does not. For example, gits inability to track file moves is a symptom.
  • vmchale 7y ago
    > audit the DAG of past commits That's a branch-based way to look at it.