My only published crate uses Pijul, and is hosted on the Nest. If any Rustaceans were unaware, you can scaffold a cargo project with Pijul using cargo new/init --vcs=pijul.
Not quite the same. Jujutsu, Gitless and Stacked Git are UIs written on top of Git. The UX is better than Git, but they inherit all the issues of not having proper theoretical foundations. Mercurial is in that category too: better UX, same problems.
Pijul solves the most basic problem of version control: all these tools try to simulate patch commutation (using mixtures of merges and rebases), but would never say it like that, while Pijul has actual commutative patches.
Yes. As someone who cares a lot about version control, I have read all I could about Jujutsu when it was first released. I actually find it nice and interesting.
What I meant in my comment above was that while I acknowledge that the snapshot model is dominant and incremental improvements are a very positive thing, I also don’t think this is the right way to look at the problem:
All the algorithms modelling these problems in the context of concurrent datastructures use changes rather than snapshots: CRDTs, OTs… (I’m talking about the “latest” version being a CRDT, here, not the entire DAG of changes).
In all the Git UIs that I know of, the user is always shown commits as patches. Why represent it differently internally?
What’s presented to the user does not need to be the internal representation. Just like users and most of the tools work on the snapshot of the source repo, yet you can represent the snapshot as a set of patches internally. That, however, does not necessarily mean either snapshot or set-of-patches works superior than the other. Besides, any practical VCS would have both representations available anyway.
Good point, and actually Pijul’s internal representation is far from being as simple as just a list of patches.
However, what I meant there wasn’t about the bytes themselves, but rather about the operations defined on the internal datastructure. When your internals model snapshots (regardless of what bytes are actually written), all your operations will be on snapshots – yet, Git never graphically shows anything as snapshots, all UIs show patches. This has real consequences visible in the real world, for example the lack of associativity (bad merges), unintelligible conflicts (hello, git rerere), endless rebases…
Also, my main interests in this project are mathematical (how to model things properly?) and technical (how to make the implementation really fast?). So, I do claim that patches can simulate snapshots at no performance penalty, whereas the converse isn’t true if you want to do a proper merge and deal with conflicts rigorously.
Yeah, I do think that, like many people have commented, collaboration networks like GitHub are one thing any new DVCS will either need to produce, or need to somehow be compatible with. Even GitHub is famously unusable for the standard kernel workflow and it could be argued that it suffers due to that.
I really like the Jujutsu compromise of allowing interop with all the common git social networks at the same time as allowing more advanced treatment of conflicts and ordering between operations.
There isn’t a document yet on how the transition to the native backend in a git social network world would look.
I also think that the operation log of jujutsu not being sharable is a limitation that would be nice to cram into some hidden data structures in the actual git repo, but then you have a chicken and egg problem of how to store that operation…
So, it seems the phrase “the most basic” was unclear in my comment above: I meant that from a theory point of view, the most basic problem is “what is a version control system?”, and that is what we tried to tackle with Pijul.
I haven’t really had the time yet to read through the documentation, but how does Pijul manage its state? A big problem with Git is that it sort of assumes everything is on disk and that you always have direct access to the data. This causes problems for large Git hosts (e.g. it was a big issue at GitLab), as it’s not feasible to give e.g. web workers access to 20+ shared disks (e.g. using NFS, yuck). The result is that at such a scale you basically end up having to write your own Git daemons with clustering support and all that. It would be nice if new VCS systems were better equipped to be used at such a scale.
Good question. Pijul can separate patches into an operational part (which contains only +/- from diffs, but with byte intervals rather than actual contents) and a contents part. Its internal datastructure works on the operational part. It is relatively efficient at the moment, but grows linearly with the size of history. We have plans to make it more efficient in the future, if this becomes a problem for some users.
When downloading a bunch of patches, the larger ones aren’t downloaded entirely if they were superseded by newer versions.
But I have to admit that while we have tested Pijul on large histories (by importing Git repos), we haven’t really used it at scale in practice. And as anyone with problems “at scale” knows, experimental measurements is what matters here.
Pijul looks very cool. Do you consider in its current state to be a production ready replacement for git? I checked the FAQ but didn’t see that question.
That’s really exciting to hear; the fact that the web UI was proprietary is something that I’d always found disappointing. What prompted the change of heart, may I ask?
My understanding is that the plan has always been to open source it, but that a closed source approach was taken at first so people would focus on contributions to the Pijul protocol rather than to the relatively unimportant CRUD app.
Exactly. Maintaining open source projects takes time, one has to prioritise. In my experience, many of the “future eager contributors” to the Nest didn’t even care to look at Pijul’s source code, which makes me seriously doubt about their exact intentions.
No change of heart. Pijul is usable now, so the focus can move on to something else. Also, I find it easier to guarantee the security (and react in case of a problem) of a web server written 100% by me.
Not that I am aware of. The sad thing is @pmeunier remains the cornerstone of this project and as far as I understand, he lack time to work on pijul these days (which is totally okay, don’t get me wrong, the amount of work he already spent on this project is tremendous).
I am curious to see what the future holds for pijul, but I am a bit pessimistic I admit.
I am curious to see what the future holds for pijul, but I am a bit pessimistic I admit.
Any concrete argument?
It is true that I haven’t had much time in the last few weeks, but that doesn’t mean Pijul is unusable, or that I won’t come back to it once my current workload lightens. Others have started contributing at a fast pace, actually.
Others have started contributing at a fast pace, actually.
That is wonderful news! I keep wishing the best for pijul, even though I don’t use it anymore. This remains a particularly inspiring software to me. Sorry if my comment sounded harsh or unjust to you, I should know better but to write about my vague pessimism when the Internet is already a sad enough place.
Sounds interesting, but i definitely don’t grok it. I get the problems it points out, but definitely don’t get how it concretely fixes them. Probably just need to mess with it to understand better.
Also, being able to swap any commit order easily sounds like an anti-feature to me. I think history should not be edited generally speaking. Making that easy sounds concerning.
The commutation feature means that rebase and merge are the same operation, or rather, that it doesn’t matter which one you do. Patches are ordered locally in each Pijul repository, but they are only partially ordered globally, by their dependencies.
What Pijul gives you is a datastructure that is aware of conflicts, and where the order of incomparable patches doesn’t matter: you’ll get the exact same snapshot with different orders.
You can still bisect locally, and you can still get tags/snapshots/version identitifiers.
What I meant in my previous reply is that if your project requires a strict ordering (some projects are like that), you can model it in Pijul: you won’t be able to push a new patch without first pushing all the previous ones.
But not all projects are like that, some projects use feature branches and want the ability to merge (and unmerge) them. Or in some cases, your coauthors are working on several things at the same time and haven’t yet found the time to clean their branches, but you want to cherrypick one of their “bugfix” patches now, without (1) waiting for the bugfix to land on main and (2) without dealing with an artificial conflict between your cherry-picking and the landed bugfix in the future.
My only published crate uses Pijul, and is hosted on the Nest. If any Rustaceans were unaware, you can scaffold a cargo project with Pijul using
cargo new/init --vcs=pijul.See also: jujutsu:
https://github.com/martinvonz/jj
Not quite the same. Jujutsu, Gitless and Stacked Git are UIs written on top of Git. The UX is better than Git, but they inherit all the issues of not having proper theoretical foundations. Mercurial is in that category too: better UX, same problems.
Pijul solves the most basic problem of version control: all these tools try to simulate patch commutation (using mixtures of merges and rebases), but would never say it like that, while Pijul has actual commutative patches.
Have you read the detailed conflicts document? https://github.com/martinvonz/jj/blob/main/docs/conflicts.md It also links to a more technical description: https://github.com/martinvonz/jj/blob/main/docs/technical/conflicts.md
Yes. As someone who cares a lot about version control, I have read all I could about Jujutsu when it was first released. I actually find it nice and interesting.
What I meant in my comment above was that while I acknowledge that the snapshot model is dominant and incremental improvements are a very positive thing, I also don’t think this is the right way to look at the problem:
All the algorithms modelling these problems in the context of concurrent datastructures use changes rather than snapshots: CRDTs, OTs… (I’m talking about the “latest” version being a CRDT, here, not the entire DAG of changes).
In all the Git UIs that I know of, the user is always shown commits as patches. Why represent it differently internally?
What’s presented to the user does not need to be the internal representation. Just like users and most of the tools work on the snapshot of the source repo, yet you can represent the snapshot as a set of patches internally. That, however, does not necessarily mean either snapshot or set-of-patches works superior than the other. Besides, any practical VCS would have both representations available anyway.
Good point, and actually Pijul’s internal representation is far from being as simple as just a list of patches.
However, what I meant there wasn’t about the bytes themselves, but rather about the operations defined on the internal datastructure. When your internals model snapshots (regardless of what bytes are actually written), all your operations will be on snapshots – yet, Git never graphically shows anything as snapshots, all UIs show patches. This has real consequences visible in the real world, for example the lack of associativity (bad merges), unintelligible conflicts (hello,
git rerere), endless rebases…Also, my main interests in this project are mathematical (how to model things properly?) and technical (how to make the implementation really fast?). So, I do claim that patches can simulate snapshots at no performance penalty, whereas the converse isn’t true if you want to do a proper merge and deal with conflicts rigorously.
Yeah, I do think that, like many people have commented, collaboration networks like GitHub are one thing any new DVCS will either need to produce, or need to somehow be compatible with. Even GitHub is famously unusable for the standard kernel workflow and it could be argued that it suffers due to that.
I really like the Jujutsu compromise of allowing interop with all the common git social networks at the same time as allowing more advanced treatment of conflicts and ordering between operations.
There isn’t a document yet on how the transition to the native backend in a git social network world would look.
I also think that the operation log of jujutsu not being sharable is a limitation that would be nice to cram into some hidden data structures in the actual git repo, but then you have a chicken and egg problem of how to store that operation…
So, it seems the phrase “the most basic” was unclear in my comment above: I meant that from a theory point of view, the most basic problem is “what is a version control system?”, and that is what we tried to tackle with Pijul.
I haven’t really had the time yet to read through the documentation, but how does Pijul manage its state? A big problem with Git is that it sort of assumes everything is on disk and that you always have direct access to the data. This causes problems for large Git hosts (e.g. it was a big issue at GitLab), as it’s not feasible to give e.g. web workers access to 20+ shared disks (e.g. using NFS, yuck). The result is that at such a scale you basically end up having to write your own Git daemons with clustering support and all that. It would be nice if new VCS systems were better equipped to be used at such a scale.
Good question. Pijul can separate patches into an operational part (which contains only +/- from diffs, but with byte intervals rather than actual contents) and a contents part. Its internal datastructure works on the operational part. It is relatively efficient at the moment, but grows linearly with the size of history. We have plans to make it more efficient in the future, if this becomes a problem for some users.
When downloading a bunch of patches, the larger ones aren’t downloaded entirely if they were superseded by newer versions.
But I have to admit that while we have tested Pijul on large histories (by importing Git repos), we haven’t really used it at scale in practice. And as anyone with problems “at scale” knows, experimental measurements is what matters here.
Have they open sourced the hosting webapp yet?
I have plans to do it really soon, that’s actually my next project for Pijul.
Is it possible to host Pijul without using Nest? Like with Git creating bare repo available via SSH? I couldn’t find that anywhere in the docs.
A very frequently asked question, yet it is a chapter of the manual, it couldn’t be much clearer: https://pijul.com/manual/working_with_others.html
Pijul looks very cool. Do you consider in its current state to be a production ready replacement for git? I checked the FAQ but didn’t see that question.
That’s really exciting to hear; the fact that the web UI was proprietary is something that I’d always found disappointing. What prompted the change of heart, may I ask?
My understanding is that the plan has always been to open source it, but that a closed source approach was taken at first so people would focus on contributions to the Pijul protocol rather than to the relatively unimportant CRUD app.
Exactly. Maintaining open source projects takes time, one has to prioritise. In my experience, many of the “future eager contributors” to the Nest didn’t even care to look at Pijul’s source code, which makes me seriously doubt about their exact intentions.
No change of heart. Pijul is usable now, so the focus can move on to something else. Also, I find it easier to guarantee the security (and react in case of a problem) of a web server written 100% by me.
Not that I am aware of. The sad thing is @pmeunier remains the cornerstone of this project and as far as I understand, he lack time to work on pijul these days (which is totally okay, don’t get me wrong, the amount of work he already spent on this project is tremendous).
I am curious to see what the future holds for pijul, but I am a bit pessimistic I admit.
Any concrete argument?
It is true that I haven’t had much time in the last few weeks, but that doesn’t mean Pijul is unusable, or that I won’t come back to it once my current workload lightens. Others have started contributing at a fast pace, actually.
That is wonderful news! I keep wishing the best for
pijul, even though I don’t use it anymore. This remains a particularly inspiring software to me. Sorry if my comment sounded harsh or unjust to you, I should know better but to write about my vague pessimism when the Internet is already a sad enough place.I really wish you all the better for
pijul(:Sounds interesting, but i definitely don’t grok it. I get the problems it points out, but definitely don’t get how it concretely fixes them. Probably just need to mess with it to understand better.
Also, being able to swap any commit order easily sounds like an anti-feature to me. I think history should not be edited generally speaking. Making that easy sounds concerning.
This is not what Pijul does. If you want a strict linear ordering in Pijul, you can have it.
Again, not claiming to grok Pijul at all, but isn’t that specifically the feature emphasized here: https://pijul.org/manual/why_pijul.html#change-commutation
I get that you don’t have to use a feature even if it exists, but having a feature means someone might use it even if that is a bad idea.
I probably just don’t understand the feature.
The commutation feature means that rebase and merge are the same operation, or rather, that it doesn’t matter which one you do. Patches are ordered locally in each Pijul repository, but they are only partially ordered globally, by their dependencies.
What Pijul gives you is a datastructure that is aware of conflicts, and where the order of incomparable patches doesn’t matter: you’ll get the exact same snapshot with different orders.
You can still bisect locally, and you can still get tags/snapshots/version identitifiers.
What I meant in my previous reply is that if your project requires a strict ordering (some projects are like that), you can model it in Pijul: you won’t be able to push a new patch without first pushing all the previous ones.
But not all projects are like that, some projects use feature branches and want the ability to merge (and unmerge) them. Or in some cases, your coauthors are working on several things at the same time and haven’t yet found the time to clean their branches, but you want to cherrypick one of their “bugfix” patches now, without (1) waiting for the bugfix to land on main and (2) without dealing with an artificial conflict between your cherry-picking and the landed bugfix in the future.
That makes a lot of sense. Thanks for the details!