8 ms·

I'm glad this made the front page. I and other of my friends have tried a few times now with varying degrees of success. For those of us pining for the days of

I'm glad this made the front page. I and other of my friends have tried a few times now with varying degrees of success. For those of us pining for the days of darcs or wanting to escape the git monoculture, Pijul is really great.

rumanator 7y ago
What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?
- vmchale 7y ago
  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 are punishing in git are not with patch-based version control.
  - 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.
- pmeunier 7y ago
  It is not at all about not being Git. The absolute best reason is that Pijul actually has the properties that people think Git has: - in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around. - in Pijul, patches commute. Most Git users try to simulate that by rebasing branches, but (1) that can mean a lot of extra work for no fundamental reason and (2) Git runs the same clunky merge algorithms to decide how to do it. - Pijul knows what a conflict is, whereas Git pretends to know, but then there's "git rerere". - in Pijul, you can clone one subdirectory of a monorepo by just pulling the patches related to that directory. Git can do partial clones as well, but only with LFS and/or submodules, which are incredibly clunky and unnatural.
  - gcb0 7y ago
    > patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final state change?
    - _nalply 7y ago
      Associativity is not about changing the order but about a different grouping: ( A B ) C = A ( B C )
      - jupp0r 7y ago
        If A, B and C are patches, you are applying C last on the left side and A last on the right.
        echo-oddly 7y ago
        You are wrong. Yes, on the left side B is applied to A, then C is applied to the result (AB). However, on the right side, C is applied to B, then the result (BC) is applied to A. A is still the left most patch in both cases. BC could depend on (the output context of) A so it wouldn't make sense to apply A to BC! BC is applied to A. A(BC)
- juped 7y ago
  No one else actually answered you - its patch theory is more advanced than the patch theory employed in darcs, operating on "pushouts" of files rather than files, which can contain ambiguous lines - the site doesn't seem to link to the paper anymore and I don't have it at hand. The upshot of this is that rather than stopping the world for "conflicts" (a real terrible misnomer that made people think they were some kind of error state rather than an ordinary part of merging) until they're resolved, "conflicted" states (i.e., ambiguous states, which are not an error!) are just another type of valid state a repository can be in after applying a set of patches (and then the resolution is just a patch that applies to the "conflicted" state). Once you know about it, it's obviously the correct theory, and "conflicts" being treated as an exceptional state is obviously wrong. However, I think this will take a few decades to trickle down into practice.
- jimbo1qaz 7y ago
  About half a year ago, I tried to merge two forks of a single program which had diverged by several years. I tried a Git merge, got halfway through conflict resolution, stashed my current changes and reset my repository, and could not reapply my partial resolution. (The proper approach would've been to manually run `git rerere` without arguments to save the current partial resolution, but I didn't know that). I redid the merge in Pijul. Pijul had a bug causing it to misread the filesystem's execute bit, and no amount of `pijul reset` would fix it. Pijul's merge conflict textual syntax was baffling as well. I think it was a stack which was pushed and popped by >>> and <<< markers, and anything under === was something I should probably remove. In the end, I did succeed in the merge, but reconciling the two projects didn't work out. (FamiTracker was based off the MFC GUI library. It was forked to 0CC-FamiTracker, and another fork ported it to a MFC compatibility layer with a cross-platform Qt backend. The MFC compatibility layer didn't support all the functionality used by 0CC-FamiTracker.)
  - carlhjerpe 7y ago
    I suggest you check out git-imerge, it's a quite handy tool for making complex/big merges simple.
    - jimbo1qaz 7y ago
      https://github.com/mhagger/git-imerge https://github.com/mhagger/git-imerge > Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch. I'm not sure this would've helped in my scenario. famitracker had no public repo, and the Qt fork and 0cc-famitracker came from different Git repositories and were rooted in different subdirectories. I created a synthetic Git and Pijul history for the purpose of this merge. But it might be helpful in other situations. I'll look into it. > Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress. This does seem useful.
- KirinDave 7y ago
  > What's the value proposition of Pijul ? A faster patch-based DVCS. Folks have done a good job explaining it below. > I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. I dunno if I agree with this, but even if we dismiss that folks should be willing to try new things. When I was teaching folks about dcvs's back in around 2009-2010 folks were also unnecessarily skeptical of any sort of change. > A tool needs to actually be better at something and add tangible value where others may not have Not really though? It just needs to be different.

rumanator 7y ago

What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?

vmchale 7y ago
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 are punishing in git are not with patch-based version control.
- 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.
pmeunier 7y ago
It is not at all about not being Git. The absolute best reason is that Pijul actually has the properties that people think Git has: - in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around. - in Pijul, patches commute. Most Git users try to simulate that by rebasing branches, but (1) that can mean a lot of extra work for no fundamental reason and (2) Git runs the same clunky merge algorithms to decide how to do it. - Pijul knows what a conflict is, whereas Git pretends to know, but then there's "git rerere". - in Pijul, you can clone one subdirectory of a monorepo by just pulling the patches related to that directory. Git can do partial clones as well, but only with LFS and/or submodules, which are incredibly clunky and unnatural.
- gcb0 7y ago
  > patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final state change?
  - _nalply 7y ago
    Associativity is not about changing the order but about a different grouping: ( A B ) C = A ( B C )
    - jupp0r 7y ago
      If A, B and C are patches, you are applying C last on the left side and A last on the right.
      - echo-oddly 7y ago
        You are wrong. Yes, on the left side B is applied to A, then C is applied to the result (AB). However, on the right side, C is applied to B, then the result (BC) is applied to A. A is still the left most patch in both cases. BC could depend on (the output context of) A so it wouldn't make sense to apply A to BC! BC is applied to A. A(BC)
juped 7y ago
No one else actually answered you - its patch theory is more advanced than the patch theory employed in darcs, operating on "pushouts" of files rather than files, which can contain ambiguous lines - the site doesn't seem to link to the paper anymore and I don't have it at hand. The upshot of this is that rather than stopping the world for "conflicts" (a real terrible misnomer that made people think they were some kind of error state rather than an ordinary part of merging) until they're resolved, "conflicted" states (i.e., ambiguous states, which are not an error!) are just another type of valid state a repository can be in after applying a set of patches (and then the resolution is just a patch that applies to the "conflicted" state). Once you know about it, it's obviously the correct theory, and "conflicts" being treated as an exceptional state is obviously wrong. However, I think this will take a few decades to trickle down into practice.
jimbo1qaz 7y ago
About half a year ago, I tried to merge two forks of a single program which had diverged by several years. I tried a Git merge, got halfway through conflict resolution, stashed my current changes and reset my repository, and could not reapply my partial resolution. (The proper approach would've been to manually run `git rerere` without arguments to save the current partial resolution, but I didn't know that). I redid the merge in Pijul. Pijul had a bug causing it to misread the filesystem's execute bit, and no amount of `pijul reset` would fix it. Pijul's merge conflict textual syntax was baffling as well. I think it was a stack which was pushed and popped by >>> and <<< markers, and anything under === was something I should probably remove. In the end, I did succeed in the merge, but reconciling the two projects didn't work out. (FamiTracker was based off the MFC GUI library. It was forked to 0CC-FamiTracker, and another fork ported it to a MFC compatibility layer with a cross-platform Qt backend. The MFC compatibility layer didn't support all the functionality used by 0CC-FamiTracker.)
- carlhjerpe 7y ago
  I suggest you check out git-imerge, it's a quite handy tool for making complex/big merges simple.
  - jimbo1qaz 7y ago
    https://github.com/mhagger/git-imerge https://github.com/mhagger/git-imerge > Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch. I'm not sure this would've helped in my scenario. famitracker had no public repo, and the Qt fork and 0cc-famitracker came from different Git repositories and were rooted in different subdirectories. I created a synthetic Git and Pijul history for the purpose of this merge. But it might be helpful in other situations. I'll look into it. > Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress. This does seem useful.
KirinDave 7y ago
> What's the value proposition of Pijul ? A faster patch-based DVCS. Folks have done a good job explaining it below. > I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. I dunno if I agree with this, but even if we dismiss that folks should be willing to try new things. When I was teaching folks about dcvs's back in around 2009-2010 folks were also unnecessarily skeptical of any sort of change. > A tool needs to actually be better at something and add tangible value where others may not have Not really though? It just needs to be different.