5 ms·

This is unreasonable. First of all, often you don't need patches, so it's premature optimization. Second, git decided specifically for the actual-state version

by runyor 8y ago

This is unreasonable. First of all, often you don't need patches, so it's premature optimization. Second, git decided specifically for the actual-state version to have this key-object store, which means you throw away not just the disadvantages but the advantages as well. Last but not least, git ALSO STORES DIFFS when it packs stuff up, which is what happens if big amounts objects need to be transferred or big amounts of old data needs to be stored. That doesn't mean pijul is a bad tool. I didn't check it out. And I really think for everyday coders who don't want to become git-gurus it would be nice to have a simpler git-like VCS, for instance. But the marketing must be updated according to the facts. Try to find features that people really care about, e.g. ease of use, e.g. integration with build tooling and docker, e.g. better federation through more automation which makes centralized servers like github go away.

pmeunier 8y ago
I'd say maybe check it out first, especially the parts about patch commutation and the problems with associativity in git merges and rebases.
feanaro 8y ago
The primary novelty of Pijul is its sound patch theory, not any kind of technical achievement like smaller repository size. I do think it's premature calling it unreasonable without understanding this aspect.
- runyor 8y ago
  Why not summarize it a little if you feel that info got lost. Technically if you need a patch you can generate it on the fly by comparing both objects (you can even do that in a bash script with `diff`, if you are willing to type in the logic to look up commit->tree->file->object-name first). So there shouldn't be anything lost. The only parameters I can see with storing diffs vs immutable objects is disk space vs processing time, which is also what git proofs by not storing old immutables and instead store diffs for old stuff (reducing space by increasing processing time).
  - vthriller 8y ago
    > Technically if you need a patch you can generate it on the fly by comparing both objects Automatically generated patches might not work in the long run in certain situations (e.g. when standard 3-line context is repetitive, making the patch applicable at multiple places in the same file). Those patches also suck at conveying actual file changes (how many actual changes start with "- }" or contain lots of context braces?); that eventually prompted me to do lots of split commits in git whose sole purpose is to make automatic diffs more readable (e.g. separate commit for indentation fix). That brings the question: can Pijul store user-formatted patches?
  - pmeunier 8y ago
    No, it's actually related to the ease of use and correctness. By design, Git lacks two fundamental properties that would make working with repositories much easier: 1. Git merge is not associative. This results in cases where Alice and Bob work together, Bob pulls Alice's work, and her lines get merged into places she's never seen (blocks of text newly introduced by Bob). 2. More importantly, Git is not commutative. This means that cherry-picking and rebasing are complex operations that change commits' ids. This forces Git users to branch (an extra step that needs to be done before starting to write), but more painfully, it sometimes forces them to do multiple steps of rebasing before being able to merge what they want, or to solve the same conflict again and again after an unlucky cherry-picking. Of course, all this could maybe be prevented by stricter planning and a more vertical organisation. But this is not how many people write code in 2019. Continuous delivery, for instance, means that teams no longer know long in advance what they are going to over the course of the project. Also, the best developers don't work in vertical teams where they get continuously told what to work on.
  - feanaro 8y ago
    Sorry, I was in a hurry and I think I mixed up articles since I think another one recently appeared on HN which pointed to a page with a much better explanation. The main idea behind Pijul (as I understand it) is that it makes merging divergent branches correct and predictable by making patch application an associative operation.[1] What this means is that that, given patches A, B and C, it should be irrelevant whether you are: 1. starting with A, applying B on top, followed by applying C 2. starting with A, applying the result of C applied on top of B all at once In other words, (AB)C = A(BC) This isn't always what happens in git because it doesn't work with patches on an abstract level. Instead, it always works with states of the branch heads (and sometimes the state of their branching point, i.e. BASE, in case of a 3-way merge). As to why this matters, [2] and [3] has practical test cases where the difference of these two approaches is observable. [3] is an example of plausible C code where the non-patch approach may produce an incorrect result. It also demonstrates the way the patch algebraic approach is able to take individual changes into account and apply edits from the second branch in the correct place in the first branch, even though the affected code has moved in the first branch in the meantime. The focus on patches has other important implications, such as the fact that branches then simply become sets of patches and cherry-picking retains the identity of patches instead of creating new, unique commits. The other important aspect of Pijul is use of efficient data structures that are naturally suited to the problem in order to avoid suboptimal algorithmic complexity. This is explained in more detail here[4]. [1]: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html [2]: https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html [3]: https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good-semantics.html https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good-seman... [4]: https://pijul.org/model/ https://pijul.org/model/

by runyor 8y ago

pmeunier 8y ago

I'd say maybe check it out first, especially the parts about patch commutation and the problems with associativity in git merges and rebases.

feanaro 8y ago

The primary novelty of Pijul is its sound patch theory, not any kind of technical achievement like smaller repository size. I do think it's premature calling it unreasonable without understanding this aspect.

runyor 8y ago
Why not summarize it a little if you feel that info got lost. Technically if you need a patch you can generate it on the fly by comparing both objects (you can even do that in a bash script with `diff`, if you are willing to type in the logic to look up commit->tree->file->object-name first). So there shouldn't be anything lost. The only parameters I can see with storing diffs vs immutable objects is disk space vs processing time, which is also what git proofs by not storing old immutables and instead store diffs for old stuff (reducing space by increasing processing time).
- vthriller 8y ago
  > Technically if you need a patch you can generate it on the fly by comparing both objects Automatically generated patches might not work in the long run in certain situations (e.g. when standard 3-line context is repetitive, making the patch applicable at multiple places in the same file). Those patches also suck at conveying actual file changes (how many actual changes start with "- }" or contain lots of context braces?); that eventually prompted me to do lots of split commits in git whose sole purpose is to make automatic diffs more readable (e.g. separate commit for indentation fix). That brings the question: can Pijul store user-formatted patches?
- pmeunier 8y ago
  No, it's actually related to the ease of use and correctness. By design, Git lacks two fundamental properties that would make working with repositories much easier: 1. Git merge is not associative. This results in cases where Alice and Bob work together, Bob pulls Alice's work, and her lines get merged into places she's never seen (blocks of text newly introduced by Bob). 2. More importantly, Git is not commutative. This means that cherry-picking and rebasing are complex operations that change commits' ids. This forces Git users to branch (an extra step that needs to be done before starting to write), but more painfully, it sometimes forces them to do multiple steps of rebasing before being able to merge what they want, or to solve the same conflict again and again after an unlucky cherry-picking. Of course, all this could maybe be prevented by stricter planning and a more vertical organisation. But this is not how many people write code in 2019. Continuous delivery, for instance, means that teams no longer know long in advance what they are going to over the course of the project. Also, the best developers don't work in vertical teams where they get continuously told what to work on.
- feanaro 8y ago
  Sorry, I was in a hurry and I think I mixed up articles since I think another one recently appeared on HN which pointed to a page with a much better explanation. The main idea behind Pijul (as I understand it) is that it makes merging divergent branches correct and predictable by making patch application an associative operation.[1] What this means is that that, given patches A, B and C, it should be irrelevant whether you are: 1. starting with A, applying B on top, followed by applying C 2. starting with A, applying the result of C applied on top of B all at once In other words, (AB)C = A(BC) This isn't always what happens in git because it doesn't work with patches on an abstract level. Instead, it always works with states of the branch heads (and sometimes the state of their branching point, i.e. BASE, in case of a 3-way merge). As to why this matters, [2] and [3] has practical test cases where the difference of these two approaches is observable. [3] is an example of plausible C code where the non-patch approach may produce an incorrect result. It also demonstrates the way the patch algebraic approach is able to take individual changes into account and apply edits from the second branch in the correct place in the first branch, even though the affected code has moved in the first branch in the meantime. The focus on patches has other important implications, such as the fact that branches then simply become sets of patches and cherry-picking retains the identity of patches instead of creating new, unique commits. The other important aspect of Pijul is use of efficient data structures that are naturally suited to the problem in order to avoid suboptimal algorithmic complexity. This is explained in more detail here[4]. [1]: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html [2]: https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html [3]: https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good-semantics.html https://tahoe-lafs.org/%7Ezooko/badmerge/concrete-good-seman... [4]: https://pijul.org/model/ https://pijul.org/model/