4 ms·

I have used professionally Darcs, Mercurial, Subversion, and Git. I love distributed version control systems, and I love Git. However, Pijul looks interesting,

I have used professionally Darcs, Mercurial, Subversion, and Git. I love distributed version control systems, and I love Git. However, Pijul looks interesting, nice work! Pijul has a number of stated strengths over Git, and looks like the version history is implemented as a CRDT from my first impression. Some of the statements make me wonder how many conflicts occur in real use. If they are equal to or less than the number it produces, great. If more than what Git produces, that's a barrier to adoption, as merge conflicts are one of the biggest pains when using Git. For me though what appears one of its biggest strengths (commutative workflow) is also its biggest drawbacks. There are so many teams that are trained in git workflow and are used to it, that getting them to switch to a completely different style of workflow in sufficient numbers will take years. Git compatibility is a key missing feature. Git had this with Subversion, and I think it's a big reason why Git won over many of the Subversion crowd.

samatman 3y ago
The basic premise of Pijul is that the way they model changes leads to better merges, fewer conflicts, and (crucially) no cases of bad merges. Git can complete merges and do it incorrectly. https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html This means that in some cases, Pijul will correctly merge where any of the git merge strategies would create a conflict. It also means that in some other (rarer) cases, Pijul will generate a conflict where git would not: git would guess, in effect, and either get it right or get it wrong. I consider both of these things to resolve in Pijul's favor. The Pijul model also means that conflicts preserve some crucial state which can be used to resolve the merge. A conflict is modeled as a specific data structure, not as special syntax intruded into the source file. One example of this is that conflicts can in some circumstance be resolved by applying more patches, because the conflict is metadata about the file, it isn't data in the file which screws with subsequent state changes.
hosh 3y ago
What I am excited about Pijul is being able to maintain a personal codebase that can accept changes from multiple upstreams. I’m not looking at commercial teams as much as homelabs or local-first environments.

samatman 3y ago

The basic premise of Pijul is that the way they model changes leads to better merges, fewer conflicts, and (crucially) no cases of bad merges. Git can complete merges and do it incorrectly. https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html This means that in some cases, Pijul will correctly merge where any of the git merge strategies would create a conflict. It also means that in some other (rarer) cases, Pijul will generate a conflict where git would not: git would guess, in effect, and either get it right or get it wrong. I consider both of these things to resolve in Pijul's favor. The Pijul model also means that conflicts preserve some crucial state which can be used to resolve the merge. A conflict is modeled as a specific data structure, not as special syntax intruded into the source file. One example of this is that conflicts can in some circumstance be resolved by applying more patches, because the conflict is metadata about the file, it isn't data in the file which screws with subsequent state changes.

hosh 3y ago

What I am excited about Pijul is being able to maintain a personal codebase that can accept changes from multiple upstreams. I’m not looking at commercial teams as much as homelabs or local-first environments.