4 ms·

The articles defines its sense of commutation as "meaning that if the two changes could be written without knowledge of each other, they can be applied in any o

The articles defines its sense of commutation as "meaning that if the two changes could be written without knowledge of each other, they can be applied in any order" But, this seems to require semantic level understanding of the code, which generally can't be done. For instance, say Alice adds a call to foo() while Bob changes foo to require some precondition that doesn't hold in Alice's case. That's going to appear to commute as these changes would touch completely separate files, but actually the resulting code won't work. In a normal git flow, this would be a case of whoever gets the commit in and passes CI first "wins", and the second commit fails CI and requires the issue to be fixed. This method seems to rely inherently on the fact that git commits are ordered. How would this work with a pijul-based flow?

deleted 6y ago
[deleted]
pmeunier 6y ago
It is actually defined as "you get the same file contents and directory structure, regardless of the order in which you apply the changes", which is quite good. > But, this seems to require semantic level understanding of the code No: you may very well have two different orders yielding the same output, even though the output is incorrect. > This method seems to rely inherently on the fact that git commits are ordered. How would this work with a pijul-based flow? Good question. Our CI over at https://nest.pijul.com/pijul/pijul/ci https://nest.pijul.com/pijul/pijul/ci works in the same way. Patches are ordered in Pijul too, but the order is local. In your example, if Alice wins, Bob will pull her patch, fix his code, which will produce another patch. He will then send it to CI again (or directly to main if he's careless), and Alice will pull both Bob's original patch and the fix. In the end, they will have different histories, but the exact same contents.
- vlovich123 6y ago
  If there’s no global history to the changes, how do you support signing off on changes with crypto keys? How do you do a post Morten analysis of the order of events that led to a problem?
  - pmeunier 6y ago
    There are global states in Pijul, using cryptographic primitives to handle the commutative nature of Pijul history. I explained it in a previous blog post: https://pijul.org/posts/2020-11-07-towards-1.0/#version-identifiers https://pijul.org/posts/2020-11-07-towards-1.0/#version-iden...

deleted 6y ago

[deleted]

pmeunier 6y ago

It is actually defined as "you get the same file contents and directory structure, regardless of the order in which you apply the changes", which is quite good. > But, this seems to require semantic level understanding of the code No: you may very well have two different orders yielding the same output, even though the output is incorrect. > This method seems to rely inherently on the fact that git commits are ordered. How would this work with a pijul-based flow? Good question. Our CI over at https://nest.pijul.com/pijul/pijul/ci https://nest.pijul.com/pijul/pijul/ci works in the same way. Patches are ordered in Pijul too, but the order is local. In your example, if Alice wins, Bob will pull her patch, fix his code, which will produce another patch. He will then send it to CI again (or directly to main if he's careless), and Alice will pull both Bob's original patch and the fix. In the end, they will have different histories, but the exact same contents.

vlovich123 6y ago
If there’s no global history to the changes, how do you support signing off on changes with crypto keys? How do you do a post Morten analysis of the order of events that led to a problem?
- pmeunier 6y ago
  There are global states in Pijul, using cryptographic primitives to handle the commutative nature of Pijul history. I explained it in a previous blog post: https://pijul.org/posts/2020-11-07-towards-1.0/#version-identifiers https://pijul.org/posts/2020-11-07-towards-1.0/#version-iden...