5 ms·

I seem to recall very positive comments regarding pijul's underlying architecture/theory. However, as I don't have the headspace to delve into it, I would love

I seem to recall very positive comments regarding pijul's underlying architecture/theory. However, as I don't have the headspace to delve into it, I would love a blurb at the beginner level that highlights the benefits of using pijul compared to other VCS, and a very brief and simple comparison between pijul and git (focusing on the differences).

psychoslave 3y ago
I think that whatever VCS come today, it will have a hard time finding a broad adoption use case that overweight the massive footprint of git ecosystem.
bondarchuk 3y ago
https://news.ycombinator.com/item?id=39452312 https://news.ycombinator.com/item?id=39452312 This comment (that probably prompted this submission) gave me some idea at least.
exDM69 3y ago
In day to day use, there's very little difference in the practical use of git vs. pijul. You edit files, commit then push. Of course the user interface is different and some of the terminology is different but it's still a distributed version control system. As for the differences, the advantages are listed right there on the front page: commutation, merge correctness, first-class conflicts and partial clones. Explaining these in more detail in a short example ("a blurb") is not really easy because you'd have to first set up an example three way merge (for example) and then study the behavior of git vs. pijul in detail. I recall seeing a video presentation from the Pijul authors which delved deep into this if you're interested. But I'll give it a go anyway... tl;dr: pijul can handle certain merge situations automatically where git requires you to manually resolve them
- vlowther 3y ago
  More than that. If you have ever had to fix a bug in code common to multiple maintained releases of a project, being able to apply the same patch to them all as its own thing instead of having multiple cherry-picked commits with identical content would be nice.
  - grepknfss 3y ago
    I think giving a patch its own identity is a pretty neat concept and clearly different than the git approach, so thanks for this example!
- pmeunier 3y ago
  You're describing working on your own single-author project, in which case there is indeed little difference (Pijul has less tooling). In practice on actual real world cases, there are lots of differences when you start working with others: even on a small project, you don't have to plan your feature branches anymore, conflicts are solved once and for all, you get free cherry-picking of bugfixes to your production branch, etc. When your project scales, there are even more differences: commutativity handles large repos for free, patches describe large files much more efficiently than by giving their whole contents (which snapshots do).
rkangel 3y ago
I have the same question every time Pijul comes up on HN, and I have yet to get an answer: Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? I am a complete believer on a sound underlying model producing better results for users at a high level, but I'm not clear on how it maps through for Pijul. I think that's what they're missing in the sell - the ability to explain to devs "it will make your life easier in the following specific ways". For example when getting my employer moved from SVN to Git I could talk to people about how much easier it was to create and then merge a temporary branch for a feature in Git. Git understand the topology of the history, knew the merge base and had better merge algos so the only pain you had was when there was an actual conflict - two people editing the same file location. It also could track renames, which were incredibly painful to merge in SVN.
- exDM69 3y ago
  > Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? Simplified example: Persons A and B check out master branch. Person A adds a.txt, commits and pushes. Person B adds b.txt, commits and tries to push and... 1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. 2) pijul will accept the change (after a pull, but no rebase) because patches A and B are independent of each other and does not matter which order they are in the history (keyword: commutation). The value of Pijul will only start to show when you get into big three way merge scenarios. Which git users avoid like the plague because they are so nasty to deal with. Demonstrating this would need a much larger example. edit: clarification a pull is still needed in case 2, but no rebase or merge because there isn't one for commutative patches
  - hombrebuffalo 3y ago
    Does that only apply to adding new files? The changes in commit A could affect the behavior of the changes in commit B even if they are different files.
trklausss 3y ago
That sounds very much like something you could copy-paste on ChatGPT and get a somewhat good answer. That you definitely would have to double check because it might be that it hallucinates.

psychoslave 3y ago

I think that whatever VCS come today, it will have a hard time finding a broad adoption use case that overweight the massive footprint of git ecosystem.

bondarchuk 3y ago

https://news.ycombinator.com/item?id=39452312 https://news.ycombinator.com/item?id=39452312 This comment (that probably prompted this submission) gave me some idea at least.

exDM69 3y ago

In day to day use, there's very little difference in the practical use of git vs. pijul. You edit files, commit then push. Of course the user interface is different and some of the terminology is different but it's still a distributed version control system. As for the differences, the advantages are listed right there on the front page: commutation, merge correctness, first-class conflicts and partial clones. Explaining these in more detail in a short example ("a blurb") is not really easy because you'd have to first set up an example three way merge (for example) and then study the behavior of git vs. pijul in detail. I recall seeing a video presentation from the Pijul authors which delved deep into this if you're interested. But I'll give it a go anyway... tl;dr: pijul can handle certain merge situations automatically where git requires you to manually resolve them

vlowther 3y ago
More than that. If you have ever had to fix a bug in code common to multiple maintained releases of a project, being able to apply the same patch to them all as its own thing instead of having multiple cherry-picked commits with identical content would be nice.
- grepknfss 3y ago
  I think giving a patch its own identity is a pretty neat concept and clearly different than the git approach, so thanks for this example!
pmeunier 3y ago
You're describing working on your own single-author project, in which case there is indeed little difference (Pijul has less tooling). In practice on actual real world cases, there are lots of differences when you start working with others: even on a small project, you don't have to plan your feature branches anymore, conflicts are solved once and for all, you get free cherry-picking of bugfixes to your production branch, etc. When your project scales, there are even more differences: commutativity handles large repos for free, patches describe large files much more efficiently than by giving their whole contents (which snapshots do).

rkangel 3y ago

I have the same question every time Pijul comes up on HN, and I have yet to get an answer: Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? I am a complete believer on a sound underlying model producing better results for users at a high level, but I'm not clear on how it maps through for Pijul. I think that's what they're missing in the sell - the ability to explain to devs "it will make your life easier in the following specific ways". For example when getting my employer moved from SVN to Git I could talk to people about how much easier it was to create and then merge a temporary branch for a feature in Git. Git understand the topology of the history, knew the merge base and had better merge algos so the only pain you had was when there was an actual conflict - two people editing the same file location. It also could track renames, which were incredibly painful to merge in SVN.

exDM69 3y ago
> Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? Simplified example: Persons A and B check out master branch. Person A adds a.txt, commits and pushes. Person B adds b.txt, commits and tries to push and... 1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. 2) pijul will accept the change (after a pull, but no rebase) because patches A and B are independent of each other and does not matter which order they are in the history (keyword: commutation). The value of Pijul will only start to show when you get into big three way merge scenarios. Which git users avoid like the plague because they are so nasty to deal with. Demonstrating this would need a much larger example. edit: clarification a pull is still needed in case 2, but no rebase or merge because there isn't one for commutative patches
- hombrebuffalo 3y ago
  Does that only apply to adding new files? The changes in commit A could affect the behavior of the changes in commit B even if they are different files.

trklausss 3y ago

That sounds very much like something you could copy-paste on ChatGPT and get a somewhat good answer. That you definitely would have to double check because it might be that it hallucinates.