3 ms·

Yes, git "recreates" the patches when you view a diff. But git can't decide that these two patches are independent of each other and thus their order does not

by exDM69 3y ago

Yes, git "recreates" the patches when you view a diff. But git can't decide that these two patches are independent of each other and thus their order does not matter so it'll give you a merge conflict where pijul doesn't. You can losslessly convert between the two models, but you can't efficiently apply patch theory (commutation etc) to a bunch of snapshots.

gugagore 3y ago
This doesn't seem to be true. I can use git rebase to change the order of commits, and I don't get conflicts if the corresponding patches are independent. If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.
- exDM69 3y ago
  Yes, of course you can manually do that. > If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model. No, this will turn into a performance nightmare. The keyword is efficiently. A patch based data model is a requirement to efficiently do the kind of deduction on patch commutativity and other properties that Pijul does. Converting back and forth on the fly using snapshots (which are a list of filenames and blob hashes) would not work outside of toy examples. And this is what eventually "killed" Darcs (an earlier patch based system), its data model had some exponential corner cases that could not be resolved.
  - gugagore 3y ago
    I can understand in principle but not actually. Converting between snapshot and patch representations is not an exponential effort operation. You could convert a git history to pijul (yes, expensive, but not exponential), do the conflict resolution in pijul land, and then handwaved convert back to snapshots.
    - pmeunier 3y ago
      The key insight of Pijul is to be the smallest generalisation of a file that is a CRDT with insertions and deletions of bytes as its two operations, where "smallest" and "file" are meant in a specific sense. The main thing that makes it all work is the extreme performance of its storage backend, which allows to manipulate a graph datastructure directly on disk, and avoid as many IO operations as possible while doing that. This works well, as all operations in Pijul (with some caveats) work in a time logarithmic in the size of history. And yet, it is slower than Git for some operations. Therefore, what you're suggesting is linear in the size of history (importing), i.e. exponentially slower than Pijul, for every single merge!

by exDM69 3y ago

gugagore 3y ago

This doesn't seem to be true. I can use git rebase to change the order of commits, and I don't get conflicts if the corresponding patches are independent. If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model.

exDM69 3y ago
Yes, of course you can manually do that. > If you can losslessly convert between the two models, then it seems like you could make git's conflict resolution smarter without changing the underlying data model. No, this will turn into a performance nightmare. The keyword is efficiently. A patch based data model is a requirement to efficiently do the kind of deduction on patch commutativity and other properties that Pijul does. Converting back and forth on the fly using snapshots (which are a list of filenames and blob hashes) would not work outside of toy examples. And this is what eventually "killed" Darcs (an earlier patch based system), its data model had some exponential corner cases that could not be resolved.
- gugagore 3y ago
  I can understand in principle but not actually. Converting between snapshot and patch representations is not an exponential effort operation. You could convert a git history to pijul (yes, expensive, but not exponential), do the conflict resolution in pijul land, and then handwaved convert back to snapshots.
  - pmeunier 3y ago
    The key insight of Pijul is to be the smallest generalisation of a file that is a CRDT with insertions and deletions of bytes as its two operations, where "smallest" and "file" are meant in a specific sense. The main thing that makes it all work is the extreme performance of its storage backend, which allows to manipulate a graph datastructure directly on disk, and avoid as many IO operations as possible while doing that. This works well, as all operations in Pijul (with some caveats) work in a time logarithmic in the size of history. And yet, it is slower than Git for some operations. Therefore, what you're suggesting is linear in the size of history (importing), i.e. exponentially slower than Pijul, for every single merge!