4 ms·

I don't understand what justifies Pijul's existence. While I agree that Git is a complicated monster that takes ages to learn how to use for most people, Pijul

I don't understand what justifies Pijul's existence. While I agree that Git is a complicated monster that takes ages to learn how to use for most people, Pijul does not seem to solve any problems with Git. Instead, it has many problems that Git solves. From a user-perspective, it doesn't even seem like there's much of a difference, despite the (annoying) choice of alternate command verbs (i.e. "record" rather than "add/commit"). It doesn't really seem like the authors fully understand Git, and what problems it solves. > [...] in Git each commit is related to a parent [...] But in Pijul there's no timeline and branches are just sets of patches. To me, that makes Pijul much, much less capable as a version control system. In Git, knowing the commit ID means that you know the full source tree state with the certainty being equal to the risk of a commit ID hash collision. With just individual, unrelated patches applied in sequence, you have no such guarantee, and no knowledge of the current state of the repository. Of course, you could add a seperate state tracking system allowing ID's to point to an immutable and unique set of patches in a certain sequence, but doing so just means that you have now implemented features identical to Git, with just a different internal representation (i.e. irrelevant differences for the user). > [...] And push those changes in whatever order we want You can do the same in Git (see interactive rebase, cherry-picking, similar). It rewrites the commit IDs in order to maintain the previously mentioned property of representing the state of the repository, but that's an implementation detail.

tomp 8y ago
Pijul is based on a different (and much more advanced) algorithm than Git. That doesn't mean it's the perfect tool - just as Git is better than SVN (even though they're based on the same underlying algorithms), Pijul might be the "SVN-like" tool waiting for its own Git... Edit: having said that, Git isn't perfect either, I'm keeping my fingers crossed for an even better tool!
- DaiPlusPlus 8y ago
  > just as Git is better than SVN (even though they're based on the same underlying algorithms) Please explain this. Git is a content-addressable object-store. SVN is not. SVN’s architecture uses a diff as the basis for versioning which ties you to a particular diffing system, git uses snapshots and diffs can be generated using any algorithm because they aren’t part of the object-store; so what common “underlying algorithms” are you referring to?
  - tomp 8y ago
    AFAIK the basic merge algorithm for both Git and SVN is 3-way diff. Pijul instead uses commutative patches and a more complex merge algorithm.
    - arghwhat 8y ago
      Is it a better merge algorithm? Complexity on its own is not a selling point. And if it is better, then I believe that it should also be possible to implement for Git, as the patch properties of Pijul and Darcs can easily be emulated.
      - tomp 8y ago
        Well if it's better at preventing bad merges, it's better, yes. Pijul might not be the best/optimal implementation of this algorithm, but it's still a step in the right direction (mainly because they optimized the algorithm significantly, reducing its complexity). Like, not all benefits of number theory (e.g. encryption) were discovered on the first day either.
      - pmeunier 8y ago
        1. It is associative, which make it predictable, and yes, better. 2. It is commutative, which makes it non-trivial to emulate with Git, a system where nothing commutes (on purpose). Of course, you can obviously do your merges manually, rebase the world at each new commit, cherry-pick and rerere to emulate what Pijul gives you for free. But then is your job writing code or showing your proficiency at Git?
  - geezerjay 8y ago
    > Please explain this. Git is a content-addressable object-store. SVN is not. They are both version control systems. People use them to track versions, as well as merging changes and diverging development branches. How data s stored is an implementation delail that doesn't reflect on the mental model.
- arghwhat 8y ago
  Git is extremely different from SVN at all levels. Pijul does not appear particularly different from Git from a high-level perspective, however. Internal implementation details are very different, but they are largely invisible to the user. It appears that Pijul is meant as an enhancement to Darcs (At least, the FAQ makes that out to be the case). Darcs which has its list of key features here: http://darcs.net/Features http://darcs.net/Features, all of which overlap entirely with Git.
  - tomp 8y ago
    Indeed, and it differs from Git in the same way as Darcs differs from Git: the basic block of history/code is not a commit, but a (commutative) patch.
    - arghwhat 8y ago
      Yes, which misses the point: Darcs does not mention any features that Git lacks, and lets its differences remain as largely invisible and irrelevant from the perspective of the user.
- johnisgood 8y ago
  > Pijul might be the "SVN-like" tool waiting for its own Git... Or Pijul is git, and Darcs is SVN in this case.
fxfan 8y ago
First and foremost- its about a mental model. Pijuls model matches how one thinks of code changes. But in terms of actual implementation- pijul has better space management (a factor that solely dictates use of mercurial often). Also- pijul has per path check out. But again- all this is implementation- what works better is mental model. Anybody who has cherry picked patch hunks or done a 3way merge knows what I'm talking about.
- arghwhat 8y ago
  1. I see no difference. Git effectively works as differences. A commit can for all intends and purposes also be considered a "patch" (that just happens to also point to the parent it is meant to be applied to). That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 2. So does git. git checkout treeish -- pathspec Pijul does not solve a three-way merge. In fact, it does not seem to mention how merges are dealt with at all. Its model does nothing to even remotely affect the situation from what I can tell.
  - pmeunier 8y ago
    > That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 1. Sorry, I get that you might be angry at Pijul for some reason, but this is simply not true. The lack of associativity of 3-way merge is absolutely not hidden, and gets merges wrong sometimes. But more fundamentally, the fact that commits must be ordered is not an implementation detail, it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository. Conflicts in Pijul are detected correctly, and a conflicting state is another valid state, whereas in Git, a conflict is a failure to merge, and the user must solve the conflict before doing anything else. In particular, this implies that a conflict resolution in Git can be propagated to other repositories only if the two conflicting commits were merged at the exact same time in all repositories. 2. Working on parts of the repository in Git only works for checkout, you still have to clone the entire repository, and Git still has the entire repo, even it is not shown to the user in its entirety. This completely defeats the point of partial clones, and prevents, in many cases, the use of Git on monorepos. That said, I'm not sure why this is the case, Git could very well produce a commit using a tree whose blobs are not all downloaded, just like when you commit from a shallow clone. But even if this worked, Git requires you to send the entire history of the full repository if you want to clone it to a remote machine, whereas Pijul lets you select the patches relative to just a part of the repository. This is because in Pijul, patches commute! If you place your patches in a sequence, you can reorder the patches you want to send (without changing their identifier) to be the first ones in the sequence, and then send just a prefix of the sequence. All this without any extra operation, rebase or anything else.
pmeunier 8y ago
May I suggest maybe reading the manual before writing this kind of comment? https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html
alkonaut 8y ago
> I don't understand what justifies Pijul's existence. The argument basically is: Darcs is better at the fundamentals than git is, and the reason for its lack of popularity is that it implemented those fundamentals inefficiently leading to exponential time use in some cases. So the justification is that some people want Darcs fundamentals but with the speed of git. Now: if you don't buy that Darcs does anything fundamentally better than git then obviously you also won't allow it as an argument for why Pijul is needed. But it is the argument. The pijul manual starts with a "Why pijul" that describes why the more complex patch theory is an advantage. https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html it outlines an example "bad merge" scenario where patches theoretic system gets it right and git does not. https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html
Sujan 8y ago
> I don't understand what justifies Pijul's existence. Someone wanted to create it, then created it, and probably had some fun while doing that.

tomp 8y ago

Pijul is based on a different (and much more advanced) algorithm than Git. That doesn't mean it's the perfect tool - just as Git is better than SVN (even though they're based on the same underlying algorithms), Pijul might be the "SVN-like" tool waiting for its own Git... Edit: having said that, Git isn't perfect either, I'm keeping my fingers crossed for an even better tool!

DaiPlusPlus 8y ago
> just as Git is better than SVN (even though they're based on the same underlying algorithms) Please explain this. Git is a content-addressable object-store. SVN is not. SVN’s architecture uses a diff as the basis for versioning which ties you to a particular diffing system, git uses snapshots and diffs can be generated using any algorithm because they aren’t part of the object-store; so what common “underlying algorithms” are you referring to?
- tomp 8y ago
  AFAIK the basic merge algorithm for both Git and SVN is 3-way diff. Pijul instead uses commutative patches and a more complex merge algorithm.
  - arghwhat 8y ago
    Is it a better merge algorithm? Complexity on its own is not a selling point. And if it is better, then I believe that it should also be possible to implement for Git, as the patch properties of Pijul and Darcs can easily be emulated.
    - tomp 8y ago
      Well if it's better at preventing bad merges, it's better, yes. Pijul might not be the best/optimal implementation of this algorithm, but it's still a step in the right direction (mainly because they optimized the algorithm significantly, reducing its complexity). Like, not all benefits of number theory (e.g. encryption) were discovered on the first day either.
    - pmeunier 8y ago
      1. It is associative, which make it predictable, and yes, better. 2. It is commutative, which makes it non-trivial to emulate with Git, a system where nothing commutes (on purpose). Of course, you can obviously do your merges manually, rebase the world at each new commit, cherry-pick and rerere to emulate what Pijul gives you for free. But then is your job writing code or showing your proficiency at Git?
- geezerjay 8y ago
  > Please explain this. Git is a content-addressable object-store. SVN is not. They are both version control systems. People use them to track versions, as well as merging changes and diverging development branches. How data s stored is an implementation delail that doesn't reflect on the mental model.
arghwhat 8y ago
Git is extremely different from SVN at all levels. Pijul does not appear particularly different from Git from a high-level perspective, however. Internal implementation details are very different, but they are largely invisible to the user. It appears that Pijul is meant as an enhancement to Darcs (At least, the FAQ makes that out to be the case). Darcs which has its list of key features here: http://darcs.net/Features http://darcs.net/Features, all of which overlap entirely with Git.
- tomp 8y ago
  Indeed, and it differs from Git in the same way as Darcs differs from Git: the basic block of history/code is not a commit, but a (commutative) patch.
  - arghwhat 8y ago
    Yes, which misses the point: Darcs does not mention any features that Git lacks, and lets its differences remain as largely invisible and irrelevant from the perspective of the user.
johnisgood 8y ago
> Pijul might be the "SVN-like" tool waiting for its own Git... Or Pijul is git, and Darcs is SVN in this case.

fxfan 8y ago

First and foremost- its about a mental model. Pijuls model matches how one thinks of code changes. But in terms of actual implementation- pijul has better space management (a factor that solely dictates use of mercurial often). Also- pijul has per path check out. But again- all this is implementation- what works better is mental model. Anybody who has cherry picked patch hunks or done a 3way merge knows what I'm talking about.

arghwhat 8y ago
1. I see no difference. Git effectively works as differences. A commit can for all intends and purposes also be considered a "patch" (that just happens to also point to the parent it is meant to be applied to). That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 2. So does git. git checkout treeish -- pathspec Pijul does not solve a three-way merge. In fact, it does not seem to mention how merges are dealt with at all. Its model does nothing to even remotely affect the situation from what I can tell.
- pmeunier 8y ago
  > That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 1. Sorry, I get that you might be angry at Pijul for some reason, but this is simply not true. The lack of associativity of 3-way merge is absolutely not hidden, and gets merges wrong sometimes. But more fundamentally, the fact that commits must be ordered is not an implementation detail, it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository. Conflicts in Pijul are detected correctly, and a conflicting state is another valid state, whereas in Git, a conflict is a failure to merge, and the user must solve the conflict before doing anything else. In particular, this implies that a conflict resolution in Git can be propagated to other repositories only if the two conflicting commits were merged at the exact same time in all repositories. 2. Working on parts of the repository in Git only works for checkout, you still have to clone the entire repository, and Git still has the entire repo, even it is not shown to the user in its entirety. This completely defeats the point of partial clones, and prevents, in many cases, the use of Git on monorepos. That said, I'm not sure why this is the case, Git could very well produce a commit using a tree whose blobs are not all downloaded, just like when you commit from a shallow clone. But even if this worked, Git requires you to send the entire history of the full repository if you want to clone it to a remote machine, whereas Pijul lets you select the patches relative to just a part of the repository. This is because in Pijul, patches commute! If you place your patches in a sequence, you can reorder the patches you want to send (without changing their identifier) to be the first ones in the sequence, and then send just a prefix of the sequence. All this without any extra operation, rebase or anything else.

pmeunier 8y ago

May I suggest maybe reading the manual before writing this kind of comment? https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html

alkonaut 8y ago

> I don't understand what justifies Pijul's existence. The argument basically is: Darcs is better at the fundamentals than git is, and the reason for its lack of popularity is that it implemented those fundamentals inefficiently leading to exponential time use in some cases. So the justification is that some people want Darcs fundamentals but with the speed of git. Now: if you don't buy that Darcs does anything fundamentally better than git then obviously you also won't allow it as an argument for why Pijul is needed. But it is the argument. The pijul manual starts with a "Why pijul" that describes why the more complex patch theory is an advantage. https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html it outlines an example "bad merge" scenario where patches theoretic system gets it right and git does not. https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html

Sujan 8y ago

> I don't understand what justifies Pijul's existence. Someone wanted to create it, then created it, and probably had some fun while doing that.