5 ms·

You’re right about not caring about the implementation level. But the difference isn’t just at the implementation level, it also relates to merging etc. See h

You’re right about not caring about the implementation level. But the difference isn’t just at the implementation level, it also relates to merging etc. See here for an example of how merging works better, by taking into account intermediate commits: https://tahoe-lafs.org/~zooko/badmerge/concrete-good-semantics.html https://tahoe-lafs.org/~zooko/badmerge/concrete-good-semanti... That is to say, start with version A, on one branch commit versions B1 and then B2, on another branch commit version C1. To merge the two branches (B2 and C1), Git/Subversion etc. will do a three-way merge of “A to B2” and “A to C1”. It won’t take into account B1 which provides vital information to do a better merge.

emmelaich 8y ago
OK, but if it's needed you could derive patches from snapshots and perform the same steps with a snapshot based VC. I may be missing something here! PS less I seem too harsh here, I love looking into version control systems. I have worked with sccs, rcs, arch, larch, bazaar, bzr, bitkeeper, svn and of course git. Looked at darcs very briefly. Never used cvs seriously. Managed to avoid clearcase thank god.
- pmeunier 8y ago
  Sure, but if you had read the manual[1], you would have learned that this is only the associativity part, which you could indeed use to provide a better merge algorithm in a snapshot-based VCS. So: 1. You're 100% correct in saying that this can be done in a snapshot-based VCS like Git, Mercurial or SVN. 2. But you're also missing the main feature of Pijul, patch commutation, also explained in the manual. The idea is that you don't need to rebase anymore, two patches produced independently always commute, and hence patches don't need to change their identity when they are "rebased", or merged at any point in time. This has major usability benefits, such as being able to undo a "merge" (I prefer to call it a patch application) even after ten other "merges". Or choosing which part of a conflict to remove in order to solve it (if you don't choose to actually solve the conflict). With patch commutation, you don't need `git rerere` anymore, and you don't even need to branch very often, since branch are essentially an emulation of commutation (then of course Pijul still has branches, but they're quite different from Git's branches, in particular they are not as essential as in Git). But then Pijul is still a young project, there are still a few bugs here and there. It is self-hosted, and we're quite happy using it for its own development (and the development of all companion libraries, Thrussh, Sanakirja…). But is it really ready for HackerNews-level flamewars? [1] https://pijul.org/manual/why_pijul.html|the https://pijul.org/manual/why_pijul.html|the manual
  - joe_fishfish 8y ago
    > In Pijul, for any two patches A and B, either A and B commute, (in other words, A and B can be applied in any order), or A depends on B, or B depends on A. This isn't exhaustive. What about the case where both patches A and B are worked on independently, and both depend on an original version of the codebase, let's call it P for parent. A and B both diverge from P and therefore require a merge, or in git, a rebase. Over my years as a developer this scenario has caused approximately 90% of the issues with git. How does Pijul tackle it?
    - Diggsey 8y ago
      You can simply incorporate both patches A and B, you don't need a separate "merge" step. If A and B have conflicts, then the resulting repo will have conflicts (but that's allowed in pijul) and you can resolve those conflicts with a third patch, C. The nice thing is that this patch C can be used to resolve those same set of conflicts, even if someone else has a completely different history. In git, when you perform a rebase, the identity of commits is lost, and so you have to constantly re-resolve the same merge conflicts when merging between branches where one of the branches has been rebased.
      - adrianmsmith 8y ago
        That sounds great. What about the situation where A and B don't have conflicts (as defined by the VCS), but still don't work. For example, based on a state of a piece of source code, e.g. A renames a method and all usages (works fine), and B introduces new code (but uses the original method name, also works fine). Merging them will not produce conflicts, but will not work. In Git I always use "--exec 'mvn clean test'" when using "git rebase", to compile the source code (which would find such rename issues) and run unit tests (which would find other issues, e.g. A introduces a new mandatory column in a database table and B introduces an INSERT statement without that column). What would be really cool is if one could say to Pijul "for any operations on this repository, execute this command to determine if the software is OK". And then forget about it. That way all operations it does it could check, and the user could never forget. I wish Git had something like that. Or have I misunderstood something? I mean, simply relying on "no conflicts implies everything's fine" is not sufficient as far as I can see?

emmelaich 8y ago

OK, but if it's needed you could derive patches from snapshots and perform the same steps with a snapshot based VC. I may be missing something here! PS less I seem too harsh here, I love looking into version control systems. I have worked with sccs, rcs, arch, larch, bazaar, bzr, bitkeeper, svn and of course git. Looked at darcs very briefly. Never used cvs seriously. Managed to avoid clearcase thank god.

pmeunier 8y ago
Sure, but if you had read the manual[1], you would have learned that this is only the associativity part, which you could indeed use to provide a better merge algorithm in a snapshot-based VCS. So: 1. You're 100% correct in saying that this can be done in a snapshot-based VCS like Git, Mercurial or SVN. 2. But you're also missing the main feature of Pijul, patch commutation, also explained in the manual. The idea is that you don't need to rebase anymore, two patches produced independently always commute, and hence patches don't need to change their identity when they are "rebased", or merged at any point in time. This has major usability benefits, such as being able to undo a "merge" (I prefer to call it a patch application) even after ten other "merges". Or choosing which part of a conflict to remove in order to solve it (if you don't choose to actually solve the conflict). With patch commutation, you don't need `git rerere` anymore, and you don't even need to branch very often, since branch are essentially an emulation of commutation (then of course Pijul still has branches, but they're quite different from Git's branches, in particular they are not as essential as in Git). But then Pijul is still a young project, there are still a few bugs here and there. It is self-hosted, and we're quite happy using it for its own development (and the development of all companion libraries, Thrussh, Sanakirja…). But is it really ready for HackerNews-level flamewars? [1] https://pijul.org/manual/why_pijul.html|the https://pijul.org/manual/why_pijul.html|the manual
- joe_fishfish 8y ago
  > In Pijul, for any two patches A and B, either A and B commute, (in other words, A and B can be applied in any order), or A depends on B, or B depends on A. This isn't exhaustive. What about the case where both patches A and B are worked on independently, and both depend on an original version of the codebase, let's call it P for parent. A and B both diverge from P and therefore require a merge, or in git, a rebase. Over my years as a developer this scenario has caused approximately 90% of the issues with git. How does Pijul tackle it?
  - Diggsey 8y ago
    You can simply incorporate both patches A and B, you don't need a separate "merge" step. If A and B have conflicts, then the resulting repo will have conflicts (but that's allowed in pijul) and you can resolve those conflicts with a third patch, C. The nice thing is that this patch C can be used to resolve those same set of conflicts, even if someone else has a completely different history. In git, when you perform a rebase, the identity of commits is lost, and so you have to constantly re-resolve the same merge conflicts when merging between branches where one of the branches has been rebased.
    - adrianmsmith 8y ago
      That sounds great. What about the situation where A and B don't have conflicts (as defined by the VCS), but still don't work. For example, based on a state of a piece of source code, e.g. A renames a method and all usages (works fine), and B introduces new code (but uses the original method name, also works fine). Merging them will not produce conflicts, but will not work. In Git I always use "--exec 'mvn clean test'" when using "git rebase", to compile the source code (which would find such rename issues) and run unit tests (which would find other issues, e.g. A introduces a new mandatory column in a database table and B introduces an INSERT statement without that column). What would be really cool is if one could say to Pijul "for any operations on this repository, execute this command to determine if the software is OK". And then forget about it. That way all operations it does it could check, and the user could never forget. I wish Git had something like that. Or have I misunderstood something? I mean, simply relying on "no conflicts implies everything's fine" is not sufficient as far as I can see?