15 ms·

Pijul: A intuitive VCS unlike Git that's based on sound theory of patches

269 points by pcr910303 6y ago

bifrost 6y ago
This looks kinda cool, looks like FreeBSD already supports this directly.
- yjftsjthsd-h 6y ago
  Just in that there's a package already?
c17r 6y ago
Blog hasn't been updated since April 2019 and, I don't know if the repo is supposed to be browser accessible, but https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul gives no useful response. Looks interesting but don't know if I'd want to rely on it. ETA: looks like their twitter account (https://twitter.com/pijul_org https://twitter.com/pijul_org) is still active to that's a good thing
- lapinot 6y ago
  afaik pmeunier is currently completely rewriting pijul (since ~1 year) privately so that he can focus on getting the important things right (core algorithms, repo representation) and not on fixing stuff. It's debatable but has been explained. Apparently we could see that 1.0 release soonish. Relevant thread: https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451/25 https://discourse.pijul.org/t/is-this-project-still-active-y...
  - c17r 6y ago
    Thanks, that thread was a good read-thru. I can understand why it was done the way it was done but it makes it difficult for outsiders to know what's up. An occasional "State of Pijul" blog post would be helpful. As we all know, the Internet is full of somewhat finished but now stagnant projects.
  - X6S1x6Okd1st 6y ago
    Last relevant comment by the Author: By the way, the main things that remain to be done before release are: make Git import incremental, at the moment it’s a one-off thing that doesn’t properly save its intermediate states. rebalance a few things between Pijul and Libpijul. Florent is taking care of this one. update the Nest for the new formats and new protocol. write documentation. In other words, we’re really close to a release.
jmt_ 6y ago
Not sure the need to mention git in the title
- lytedev 6y ago
  git is the de facto VCS, so comparisons to it provide a reasonable baseline for comparison for possible users.
deleted 6y ago
[deleted]
hinkley 6y ago
I was digging into tutorials about Git internals recently and was surprised to learn just how straightforward the data structures are. Given how stupid-simple the data is, I'm all the more confused about how straightforward the CLI isn't. There are very few if any ways to accumulate and amplify errors in the system. It's no wonder Linus created a working prototype so fast. It's the simplest thing that could possibly work. But this simplicity is also the reason why binaries occupy so much space. A system can be so simple that there are obviously no errors, or so complex that no errors are obvious. In the middle ground we get progress by someone mathematically proving the soundness of a technique, and then a group of people working together to match the implementation verbatim to the proven technique. Pijul seems to be stepping into that middle space, but it's not clear to me if we're going to follow, or if something else like it will get us moving. I do like the concept, but as someone else stated, it doesn't seem to be very lively right now.
- eslaught 6y ago
  If you've ever used Darcs, that might help motivate why Pijul is interesting. Darcs was the first system I used with an interactive mode, sort of like `git add -i`. Obviously that's a UX-side change that can be (and has been) replicated in Git. But at the time it was fairly mind-blowing to work that way. The other part is the theory of patches. Darcs took the lead here too, but the algorithms and implementation left something to be desired. So Pijul could be really cool if it finally gets this to really work. On the other hand, if I'm being honest, all of my really hairy merge conflicts are not things that I think could be resolved by this---not without changing the way we think about code from being about text to being about ASTs. So I'm not sure if Pijul would have any practical day to day consequences for me. Certainly, when I moved from Darcs to Git, aside from UX issues, I don't think I noticed any major practical headaches due to the loss of the theory of patches.
  - hinkley 6y ago
    A tool that handles a frequent but not particularly challenging problem is still a net win. Humans make errors. The more times I have to do something manually, the higher the likelihood I have screwed one of them up. I don't expect to get better at doing a task the 101st time. But I do expect the odds that one of them gets cocked up to climb ever so slightly. Better if the machine can just do it. If the majority of the code is written by middle-of-the-road team members, then most of the merges will be done by those same people. Something that never helps me with my changes still helps me, due to my shared responsibility for the project. This is an often overlooked aspect of the tool selection process.
aidenn0 6y ago
Can someone with more domain knowledge than I comment on whether or not this project is mathematically possible? I remember the reason given for not making git patching sound was because all the sound algorithms known to the git author were slower in the common case, and only better in less common cases. Darcs is really fast for what it does, but git is way faster by doing less.
- tom_mellior 6y ago
  The actual execution time of local git commands is never noticeable in my work. The time spent cleaning up merge conflicts is very noticeable though. I could very well imagine being faster overall with a tool that runs half a second longer every time I commit, but that saves me from cleaning up cases where it couldn't figure out a merge.
  - aidenn0 6y ago
    I find that if you spend a lot of time on conflict resolution, it may be an indication your workflow is fighting git. There is a lot of really bad advice on git workflows out there and even worse workflows in the real world. I think gitworkflow(7) should be required reading, as it explains not just how, but why the kernel uses git the way it does
    - tom_mellior 6y ago
      Do you mean https://git-scm.com/docs/gitworkflows https://git-scm.com/docs/gitworkflows ? It doesn't seem to say anything about the kernel. Maybe you mean something else. Our workflow isn't in conflict with any of this, but some parts of our codebase evolve quickly, so topic branches regularly need to merge or rebase conflicting stuff.
- nestorD 6y ago
  It is mathematicaly possible but has not been for a very long time. Darcs algorithms suffer from complexity problems that have now been theorically solved, Pijul implements those new algorithms in the hope of getting both a good runtime and better properties than git. For some resources on the underlying algorithms, see: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html
samatman 6y ago
Ah I was hoping this meant the rewrite had landed. Should be soon, judging by the discourse. Looking forward to it.
moshimoshir 6y ago
I'm going to switch to pijul for personal work but would miss magit.
- kqr 6y ago
  Yeah, for better or worse, Magit, Ediff, and Smerge solved pretty much all of my problems with Git. Now if only I could convince my co-workers to use Git "correctly" with the help of these tools... I think that's a place where things like Pijul has a chance to shine. Some people (perhaps rightly) are just not interested in learning the tooling and extra work around Git that makes Git even more powerful. They're relatively happy with following out of the box defaults, even if it doesn't lead to a great experience. Something like Pijul might ship with the better default experience.
  - rkangel 6y ago
    Magit is great, but it's 'just' an interface. It makes things easier but it doesn't affect your git work flow. How would you benefit from other people using it?
    - kqr 6y ago
      It's a complete and sensible enough interface that whatever i want to do during normal work, Magit can present it in a very intuitive interface and it's easy to do as the default. With less complete interfaces, other people have to fall back to the git CLI interface, which is unintuitive enough to discourage fairly routine operations of branch manipulation.
mhh__ 6y ago
In the sense that git was noticeably "better" than the centralized systems that came before it, is enough wrong with git to not use it these days? Although there are pain points with git, a large majority of git activities are fairly cookie-cutter
- gnufx 6y ago
  That seems to suggest there weren't distributed systems before git (like the proprietary one git was written to replace). I think there's enough wrong with git after long experience with revision control in collaborations; I've been quote happy with Darcs.
  - stevekemp 6y ago
    Darcs was technically interesting, and also a joy to use. However it suffered from the exponential merge problem, which I think is still not fully resolved. Once you hit that all the theory and nicities went out of the window.
    - gnufx 6y ago
      The merge complexity in darcs 2 really hasn't been an issue in my usage. As I understand it, it is resolved for darcs 3, but maybe I misunderstood that from skimming what was going on. (The new theory seems to be different to Pijul's, and perhaps inferior.) I'd be happy with either as a joy to use.
      - stevekemp 6y ago
        I/we definitely hit it in real life, sufficiently often that it became obvious we needed to move to another solution. At the time it was probably CVS to darcs, then it became darcs -> hg, and giving in to the inevitable it became git.
    - chriswarbo 6y ago
      > Darcs was technically interesting, and also a joy to use. However it suffered from the exponential merge problem, which I think is still not fully resolved. That's kind of the point of Pijul
anordal 6y ago
> you can "unapply" (or "unrecord") changes made in the past, without having to change the identity of new patches (without "rebasing", in git terms). So I the identity of a patch doesn't depend on history? Nice! I wish git was like that. In fact, every time I rebase on master, I wish so.
- guitarbill 6y ago
  i'm not sure if this project is different, but patches can suck really bad. an example of this are mercurial queues (mq). with no history/ancestry, the merge behaviour can be horrible. for even medium-size teams, it goes downhill quickly. IMO, it's fucking broken and a huge waste of time. of course, it's possible i don't get mq. but i'll take git any day of the week over mercurial + mq, at least git works and doesn't loose my work as often. (believe it or not, this is easier to do with mq than git (!).) maybe pijul is different, but their "conflict" doco doesn't fill me with confidence: https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html
  - gnufx 6y ago
    > maybe pijul is different No "maybe"; that's the point. Why does modelling something fundamental, like conflicts, decrease confidence in the approach?
    - guitarbill 6y ago
      > Patches can be applied to a conflicting repository, leaving the conflict resolution for later. (from the docs) but you still have to resolve the conflicts at some point, right? and it doesn't say how this is done. so it isn't clear if this approach is less painful in practice when you apply a bunch of patches.
      - gnufx 6y ago
        I haven't used pijul, but I'm familiar with darcs and manually resolving the conflict with a new patch. You still have the conflicting patches, which you can manipulate. There's no claim of magic resolution, and I don't see why having it in the model is a negative.
albertop 6y ago
Everything old is new again. This is how Smalltalk managed changes. Simple and straightforward.
- computerphage 6y ago
  The Pijul website says their patch model is "based on a result from category theory" and they link to a paper from 2013. But wasn't Smalltalk invented in the 70s? It seems to me that either the paper wasn't novel or that Smalltalk used a different system. Why do you believe it's the same?
  - galaxyLogic 6y ago
    Good question. I'm not equipped to answer that. But let me share what I know about Smalltalk's change-management. Smalltalk has the concept of "change-list". Because in Smalltalk-the-language everything is a class or method, the change-list is basically a list of method-versions. The "unit of change" is a method. In GIT the unit of change is a "file" and a file can have arbitrary content. In Smalltalk the change-history is much more semantic because it is based on the semantic concepts of "class" and "method". Smalltalk change-list knows which methods of which classes were changed and how and when (and by whom). The user does not need to read changes within a text-file and then try to understand for themselves what semantic constructs were changed in that file in that commit. Git is programming-language-neutral vs Smalltalk change-history is specific to the concept of "classes with methods". It could as easily apply to any OOP language as far as I can see.
    - creata 6y ago
      The unit of change in Pijul is also a file, which is a finite sequence of lines, generalized to a finite directed graph of lines to deal with conflicts. The idea of a patch-based VCS is as old as the idea of a VCS. Pijul's theory of patches, and the techniques it uses to keep things speedy, are pretty new.
    - cwp 6y ago
      I did a lot of work in Smalltalk earlier in my career, and it's still the best toolset I've ever used. On one hand, yes, having the method as the unit of code is great. You just avoid all sorts of editing and versioning of non-semantic textual changes like you have in other languages. And it was really easy to look over your list of changes to see who did what when, or group them together to form larger patches. On the other hand, collaborating with bare change sets was difficult. With no dependency tracking it was just a manually-maintained bag of class-and-method definitions. You could write those out to a file and import them into another image, but it was hard to make sure you had all the necessary bits. This led to several Smalltalk-specific VCSs. The early ones were powerful, but basically required you to be connected to the net to do any work, because they were constantly communicating with a central server as you worked. Later ones were more snapshot based. I think Monticello was the first real distributed VCS - it preceded git by a couple of years. What's interesting about Pijul is it gives you that "maintaining a set of patches" workflow that made early Smalltalk change management so pleasant, but also tracks dependencies between the patches so that you can easily mix and match functionality without anything getting left out. The ultimate tool would be something that combines Pijul's theory of patches with Smalltalks semantic versioning. That would be amazing.
garmaine 6y ago
The biggest turn off for pijul right now is I can’t install it. I try cloning the latest source from the Nest, and it crashes partway through. The crashing is probabilistic, but the repo is large enough that it is guaranteed to happen. This problem has existed unfixed for a year and a half. This does not instill confidence.
- woggy 6y ago
  It's gone through a complete rewrite. The developer has stated recently that the rewrite will be released soon.
  - garmaine 6y ago
    Yes but if the developer experience is that for a year and a half they can’t fix a bug that is preventing people from doing the first step of engaging with the source code, that doesn’t bode well.
pablo1 6y ago
I can't find much talks or examples of it, any good recourses besides the official page?
dilap 6y ago
They're in the middle of a big rewrite, which will be out Real Soon Now. To understand the basic idea, this series of blog posts is excellent: https://jneem.github.io/merging/ https://jneem.github.io/merging/ To me, it seems clear that a patch-based VCS is the future. Whether or not it will be pijul that brings us this future, I don't know...
- polytely 6y ago
  The idea of composing patches really reminds me of of a series of blogposts I read about how Google Wave worked, I think it was called Operational Transformations it has seemingly disappeared from the internet but I remember it being a mind-blowing read at the time.
  - datashaman 6y ago
    https://en.wikipedia.org/wiki/Operational_transformation https://en.wikipedia.org/wiki/Operational_transformation
- dmos62 6y ago
  > patch-based VCS is the future Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one into a patch and vice-versa.
  - natsch 6y ago
    Not exactly, git creates a snapshot of the working tree for every commit. The clever bit is that the object store stores files by their hashes, so if two snapshots have identical files they won't be stored twice.
    - shock 6y ago
      I don't know who flagged this comment and why, because this comment is correct.
  - cjallen88 6y ago
octopoc 6y ago
What's the relationship between its data structures and CRDTs? The emphasis on patches makes me think this might be an operation-based CRDT.
- creata 6y ago
  You can find an explanation of how it works at [0]. The vague notion of "patch commutation" is central to both operational CRDTs and Pijul's theory of patches, but other than that, I don't really see any similarities. [0]: https://jneem.github.io/merging/ https://jneem.github.io/merging/
- pmeunier 6y ago
  Pijul is a CRDT. The main new idea is that it the smallest generalisation of text files that is a CRDT while keeping important properties such as the relative order of parts of the file.
sally1620 6y ago
There are a lot of good VCS systems, but it seems like nothing can compete with Git in popularity.
- theamk 6y ago
  Well, it's hard to beat the combination of very simple data model and lots of convenient commands. The convenient commands means everyone has their own workflow. Someone might want to create "ideal commits" instantly. Someone else might interactive rebase all the time. Yet another person can cherry-pick. Or soft reset and re-commit. Keep few branches or many branches. Or do all the work one one personal branch and pick the relevant commits later. The simple data model means you don't have to understand what the other person did in order to work with their changes. You can work you way, they can work their way, but the commits are all the same. It is a tree of files with name and parents attached to it.
phreack 6y ago
I realize this is an old project and that it's not a big deal and that this may seem childish and many other disclaimers. But. Pija is a specific synonym for penis in many Spanish dialects, so this tool's name reads like Dickul in English, which is something I think the owners should be aware of if they're not already.
- baq 6y ago
  See also Coq, the theorem prover.
  - AlexanderDhoore 6y ago
    Git also isn't a very nice word. https://www.merriam-webster.com/dictionary/git https://www.merriam-webster.com/dictionary/git
    - kkarakk 6y ago
      Git doesn't have sexual connotations. any term with sexual connotations is a hot potato nowadays in software biz/collaboration
      - PedroBatista 6y ago
        Everything is a hot potato when your basic needs are met and you’re bored and more importantly you desperately feel the need be “right” about something, perhaps listened.
- mumblerino 6y ago
  But Pija is not part of the name; Pij is. Italians use Fica for the female counterpart, and the national automobile company recently formed FCA. People joked about it and then everyone moved on.
- igitur 6y ago
  I think you'll struggle to find a human pronouncable 5 (or fewer) letter word that doesn't mean something nasty in some language.
ZuLuuuuuu 6y ago
Is Pijul something worth to look at if I am also interested in versioning binary file involving workflows? For example if I am an electronics engineer doing PCB design work? Or is it most suited for software projects with text based files?
- howling 6y ago
  Not an expert but I think it is only suitable for text file since most diff algorithms assume the files are made of not-very-long lines.
- pmeunier 6y ago
  It depends: the main issue is the diff algorithm. Pijul's diff is not line-based, but rather "byte block"-based (which at the moment happen to be lines). This means that we could totally imagine more clever diff algorithms for specific use cases. I don't know anything about PCB design files, but an example application of this is to treat indentation and spaces as their own blocks.
rkangel 6y ago
Pijul has come up a few times. Can someone help me answer the 'how would it help me' question? Under what real development scenario(s) would Pijul's approach help me?
- chriswarbo 6y ago
  It's a distributed version control system, implementing a sound mathematical model of software development (patch theory). In this sense pijul is like darcs, but it doesn't suffer from exponential-time edge cases when merging; hence it should be a pareto improvement. Of course, the elephant in the room is git: when git came out, most darcs users (eventually) switched over to it. Hence there's not many darcs users left for which pijul would be a no-brainer. There are many git users, most of whom have never used a patch-based DVCS, who would need a more compelling reason to switch. Personally, I'm glad the patch-based approach is still going, as it's always good to have competition. Plus, having a sound underlying model usually brings insights to a problem which aren't at all clear in more 'cobbled together' solutions like git (e.g. commutativity of patches is quite a natural property in darcs/pijul, which doesn't directly make sense in git due to its "commits" specifying their parents).
  - JulianWasTaken 6y ago
    I haven't made up my own mind, and certainly intend to try this out. But I want to point out that your first paragraph offers no answer to the question, same as the title here doesn't. And I don't say that to be snarky -- what you list are implementation details, not an answer to the question. As a developer I don't care what kind of theory my program is built on I just want to know how it will save me time and give me new functionality. (In my spare time I can think the math is cool and be content with that). (Even more specifically -- git is a DVCS already, it's just most people seem to use it with a central server like GitHub, so personally I also didn't understand what the page meant when calling that one of pijul's advantages).
    - rkangel 6y ago
      In principle I do care about the fundamental model being correct - that can often bubble up to fewer (or cleaner) edge cases. Without help though, or many hours of usage I can't mentally map that model to what it is actually going to be like to use.
im3w1l 6y ago
The authors are obviously very proud of their clever algorithms, but as a user my main concern is not the implementation details. My main concern is what can this tool do for me? What are the new and amazing features I can use? Or which operations go faster?
faitswulff 6y ago
I happened to be looking around to see if there was a rust rewrite of rsync last night and stumbled across this post by the author of pijul that helps explain the benefits of pijul over git: > Git is great in many ways, but doesn't really know how to merge changes correctly. Even worse, it doesn't know how to "unmerge" changes. > It does try to merge branches, though, but doesn't give you any reliable guarantee on the result. For the unmerging part, it doesn't even try and you have to rebase your changes yourself, still without strong guarantees. > Pijul uses a patch algebra to do these things, where patches have several nice properties: > • Any two patches A and B either commute, or one of them explicitly references the other. This means that repositories behave as _sets of patches_ rather than as a linear history. > • Patches are associative: applying C on top of a repository that has A and B will yield the same result as applying B and then C on top of a repository that has A. Git could have this, but unfortunately, it doesn't. > • Patches have inverse patches. > We also have a sane internal representation of conflicts, so that all conflicts don't have to be solved immediately after merging. > I should add that Pijul is still quite unstable, and at this particular moment is in the middle of a giant protocol change. https://www.reddit.com/r/rust/comments/821sgo/announcing_rustsync_a_purerust_implementation_of/dv7cibj/ https://www.reddit.com/r/rust/comments/821sgo/announcing_rus...

269 points by pcr910303 6y ago

bifrost 6y ago

This looks kinda cool, looks like FreeBSD already supports this directly.

yjftsjthsd-h 6y ago
Just in that there's a package already?

c17r 6y ago

Blog hasn't been updated since April 2019 and, I don't know if the repo is supposed to be browser accessible, but https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul gives no useful response. Looks interesting but don't know if I'd want to rely on it. ETA: looks like their twitter account (https://twitter.com/pijul_org https://twitter.com/pijul_org) is still active to that's a good thing

lapinot 6y ago
afaik pmeunier is currently completely rewriting pijul (since ~1 year) privately so that he can focus on getting the important things right (core algorithms, repo representation) and not on fixing stuff. It's debatable but has been explained. Apparently we could see that 1.0 release soonish. Relevant thread: https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451/25 https://discourse.pijul.org/t/is-this-project-still-active-y...
- c17r 6y ago
  Thanks, that thread was a good read-thru. I can understand why it was done the way it was done but it makes it difficult for outsiders to know what's up. An occasional "State of Pijul" blog post would be helpful. As we all know, the Internet is full of somewhat finished but now stagnant projects.
- X6S1x6Okd1st 6y ago
  Last relevant comment by the Author: By the way, the main things that remain to be done before release are: make Git import incremental, at the moment it’s a one-off thing that doesn’t properly save its intermediate states. rebalance a few things between Pijul and Libpijul. Florent is taking care of this one. update the Nest for the new formats and new protocol. write documentation. In other words, we’re really close to a release.

jmt_ 6y ago

Not sure the need to mention git in the title

lytedev 6y ago
git is the de facto VCS, so comparisons to it provide a reasonable baseline for comparison for possible users.

deleted 6y ago

[deleted]

hinkley 6y ago

I was digging into tutorials about Git internals recently and was surprised to learn just how straightforward the data structures are. Given how stupid-simple the data is, I'm all the more confused about how straightforward the CLI isn't. There are very few if any ways to accumulate and amplify errors in the system. It's no wonder Linus created a working prototype so fast. It's the simplest thing that could possibly work. But this simplicity is also the reason why binaries occupy so much space. A system can be so simple that there are obviously no errors, or so complex that no errors are obvious. In the middle ground we get progress by someone mathematically proving the soundness of a technique, and then a group of people working together to match the implementation verbatim to the proven technique. Pijul seems to be stepping into that middle space, but it's not clear to me if we're going to follow, or if something else like it will get us moving. I do like the concept, but as someone else stated, it doesn't seem to be very lively right now.

eslaught 6y ago
If you've ever used Darcs, that might help motivate why Pijul is interesting. Darcs was the first system I used with an interactive mode, sort of like `git add -i`. Obviously that's a UX-side change that can be (and has been) replicated in Git. But at the time it was fairly mind-blowing to work that way. The other part is the theory of patches. Darcs took the lead here too, but the algorithms and implementation left something to be desired. So Pijul could be really cool if it finally gets this to really work. On the other hand, if I'm being honest, all of my really hairy merge conflicts are not things that I think could be resolved by this---not without changing the way we think about code from being about text to being about ASTs. So I'm not sure if Pijul would have any practical day to day consequences for me. Certainly, when I moved from Darcs to Git, aside from UX issues, I don't think I noticed any major practical headaches due to the loss of the theory of patches.
- hinkley 6y ago
  A tool that handles a frequent but not particularly challenging problem is still a net win. Humans make errors. The more times I have to do something manually, the higher the likelihood I have screwed one of them up. I don't expect to get better at doing a task the 101st time. But I do expect the odds that one of them gets cocked up to climb ever so slightly. Better if the machine can just do it. If the majority of the code is written by middle-of-the-road team members, then most of the merges will be done by those same people. Something that never helps me with my changes still helps me, due to my shared responsibility for the project. This is an often overlooked aspect of the tool selection process.

aidenn0 6y ago

Can someone with more domain knowledge than I comment on whether or not this project is mathematically possible? I remember the reason given for not making git patching sound was because all the sound algorithms known to the git author were slower in the common case, and only better in less common cases. Darcs is really fast for what it does, but git is way faster by doing less.

tom_mellior 6y ago
The actual execution time of local git commands is never noticeable in my work. The time spent cleaning up merge conflicts is very noticeable though. I could very well imagine being faster overall with a tool that runs half a second longer every time I commit, but that saves me from cleaning up cases where it couldn't figure out a merge.
- aidenn0 6y ago
  I find that if you spend a lot of time on conflict resolution, it may be an indication your workflow is fighting git. There is a lot of really bad advice on git workflows out there and even worse workflows in the real world. I think gitworkflow(7) should be required reading, as it explains not just how, but why the kernel uses git the way it does
  - tom_mellior 6y ago
    Do you mean https://git-scm.com/docs/gitworkflows https://git-scm.com/docs/gitworkflows ? It doesn't seem to say anything about the kernel. Maybe you mean something else. Our workflow isn't in conflict with any of this, but some parts of our codebase evolve quickly, so topic branches regularly need to merge or rebase conflicting stuff.
nestorD 6y ago
It is mathematicaly possible but has not been for a very long time. Darcs algorithms suffer from complexity problems that have now been theorically solved, Pijul implements those new algorithms in the hope of getting both a good runtime and better properties than git. For some resources on the underlying algorithms, see: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html

samatman 6y ago

Ah I was hoping this meant the rewrite had landed. Should be soon, judging by the discourse. Looking forward to it.

moshimoshir 6y ago

I'm going to switch to pijul for personal work but would miss magit.

kqr 6y ago
Yeah, for better or worse, Magit, Ediff, and Smerge solved pretty much all of my problems with Git. Now if only I could convince my co-workers to use Git "correctly" with the help of these tools... I think that's a place where things like Pijul has a chance to shine. Some people (perhaps rightly) are just not interested in learning the tooling and extra work around Git that makes Git even more powerful. They're relatively happy with following out of the box defaults, even if it doesn't lead to a great experience. Something like Pijul might ship with the better default experience.
- rkangel 6y ago
  Magit is great, but it's 'just' an interface. It makes things easier but it doesn't affect your git work flow. How would you benefit from other people using it?
  - kqr 6y ago
    It's a complete and sensible enough interface that whatever i want to do during normal work, Magit can present it in a very intuitive interface and it's easy to do as the default. With less complete interfaces, other people have to fall back to the git CLI interface, which is unintuitive enough to discourage fairly routine operations of branch manipulation.

mhh__ 6y ago

In the sense that git was noticeably "better" than the centralized systems that came before it, is enough wrong with git to not use it these days? Although there are pain points with git, a large majority of git activities are fairly cookie-cutter

gnufx 6y ago
That seems to suggest there weren't distributed systems before git (like the proprietary one git was written to replace). I think there's enough wrong with git after long experience with revision control in collaborations; I've been quote happy with Darcs.
- stevekemp 6y ago
  Darcs was technically interesting, and also a joy to use. However it suffered from the exponential merge problem, which I think is still not fully resolved. Once you hit that all the theory and nicities went out of the window.
  - gnufx 6y ago
    The merge complexity in darcs 2 really hasn't been an issue in my usage. As I understand it, it is resolved for darcs 3, but maybe I misunderstood that from skimming what was going on. (The new theory seems to be different to Pijul's, and perhaps inferior.) I'd be happy with either as a joy to use.
    - stevekemp 6y ago
      I/we definitely hit it in real life, sufficiently often that it became obvious we needed to move to another solution. At the time it was probably CVS to darcs, then it became darcs -> hg, and giving in to the inevitable it became git.
  - chriswarbo 6y ago
    > Darcs was technically interesting, and also a joy to use. However it suffered from the exponential merge problem, which I think is still not fully resolved. That's kind of the point of Pijul

anordal 6y ago

> you can "unapply" (or "unrecord") changes made in the past, without having to change the identity of new patches (without "rebasing", in git terms). So I the identity of a patch doesn't depend on history? Nice! I wish git was like that. In fact, every time I rebase on master, I wish so.

guitarbill 6y ago
i'm not sure if this project is different, but patches can suck really bad. an example of this are mercurial queues (mq). with no history/ancestry, the merge behaviour can be horrible. for even medium-size teams, it goes downhill quickly. IMO, it's fucking broken and a huge waste of time. of course, it's possible i don't get mq. but i'll take git any day of the week over mercurial + mq, at least git works and doesn't loose my work as often. (believe it or not, this is easier to do with mq than git (!).) maybe pijul is different, but their "conflict" doco doesn't fill me with confidence: https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html
- gnufx 6y ago
  > maybe pijul is different No "maybe"; that's the point. Why does modelling something fundamental, like conflicts, decrease confidence in the approach?
  - guitarbill 6y ago
    > Patches can be applied to a conflicting repository, leaving the conflict resolution for later. (from the docs) but you still have to resolve the conflicts at some point, right? and it doesn't say how this is done. so it isn't clear if this approach is less painful in practice when you apply a bunch of patches.
    - gnufx 6y ago
      I haven't used pijul, but I'm familiar with darcs and manually resolving the conflict with a new patch. You still have the conflicting patches, which you can manipulate. There's no claim of magic resolution, and I don't see why having it in the model is a negative.

albertop 6y ago

Everything old is new again. This is how Smalltalk managed changes. Simple and straightforward.

computerphage 6y ago
The Pijul website says their patch model is "based on a result from category theory" and they link to a paper from 2013. But wasn't Smalltalk invented in the 70s? It seems to me that either the paper wasn't novel or that Smalltalk used a different system. Why do you believe it's the same?
- galaxyLogic 6y ago
  Good question. I'm not equipped to answer that. But let me share what I know about Smalltalk's change-management. Smalltalk has the concept of "change-list". Because in Smalltalk-the-language everything is a class or method, the change-list is basically a list of method-versions. The "unit of change" is a method. In GIT the unit of change is a "file" and a file can have arbitrary content. In Smalltalk the change-history is much more semantic because it is based on the semantic concepts of "class" and "method". Smalltalk change-list knows which methods of which classes were changed and how and when (and by whom). The user does not need to read changes within a text-file and then try to understand for themselves what semantic constructs were changed in that file in that commit. Git is programming-language-neutral vs Smalltalk change-history is specific to the concept of "classes with methods". It could as easily apply to any OOP language as far as I can see.
  - creata 6y ago
    The unit of change in Pijul is also a file, which is a finite sequence of lines, generalized to a finite directed graph of lines to deal with conflicts. The idea of a patch-based VCS is as old as the idea of a VCS. Pijul's theory of patches, and the techniques it uses to keep things speedy, are pretty new.
  - cwp 6y ago
    I did a lot of work in Smalltalk earlier in my career, and it's still the best toolset I've ever used. On one hand, yes, having the method as the unit of code is great. You just avoid all sorts of editing and versioning of non-semantic textual changes like you have in other languages. And it was really easy to look over your list of changes to see who did what when, or group them together to form larger patches. On the other hand, collaborating with bare change sets was difficult. With no dependency tracking it was just a manually-maintained bag of class-and-method definitions. You could write those out to a file and import them into another image, but it was hard to make sure you had all the necessary bits. This led to several Smalltalk-specific VCSs. The early ones were powerful, but basically required you to be connected to the net to do any work, because they were constantly communicating with a central server as you worked. Later ones were more snapshot based. I think Monticello was the first real distributed VCS - it preceded git by a couple of years. What's interesting about Pijul is it gives you that "maintaining a set of patches" workflow that made early Smalltalk change management so pleasant, but also tracks dependencies between the patches so that you can easily mix and match functionality without anything getting left out. The ultimate tool would be something that combines Pijul's theory of patches with Smalltalks semantic versioning. That would be amazing.

garmaine 6y ago

The biggest turn off for pijul right now is I can’t install it. I try cloning the latest source from the Nest, and it crashes partway through. The crashing is probabilistic, but the repo is large enough that it is guaranteed to happen. This problem has existed unfixed for a year and a half. This does not instill confidence.

woggy 6y ago
It's gone through a complete rewrite. The developer has stated recently that the rewrite will be released soon.
- garmaine 6y ago
  Yes but if the developer experience is that for a year and a half they can’t fix a bug that is preventing people from doing the first step of engaging with the source code, that doesn’t bode well.

pablo1 6y ago

I can't find much talks or examples of it, any good recourses besides the official page?

dilap 6y ago

They're in the middle of a big rewrite, which will be out Real Soon Now. To understand the basic idea, this series of blog posts is excellent: https://jneem.github.io/merging/ https://jneem.github.io/merging/ To me, it seems clear that a patch-based VCS is the future. Whether or not it will be pijul that brings us this future, I don't know...

polytely 6y ago
The idea of composing patches really reminds me of of a series of blogposts I read about how Google Wave worked, I think it was called Operational Transformations it has seemingly disappeared from the internet but I remember it being a mind-blowing read at the time.
- datashaman 6y ago
  https://en.wikipedia.org/wiki/Operational_transformation https://en.wikipedia.org/wiki/Operational_transformation
dmos62 6y ago
> patch-based VCS is the future Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one into a patch and vice-versa.
- natsch 6y ago
  Not exactly, git creates a snapshot of the working tree for every commit. The clever bit is that the object store stores files by their hashes, so if two snapshots have identical files they won't be stored twice.
  - shock 6y ago
    I don't know who flagged this comment and why, because this comment is correct.
- cjallen88 6y ago

octopoc 6y ago

What's the relationship between its data structures and CRDTs? The emphasis on patches makes me think this might be an operation-based CRDT.

creata 6y ago
You can find an explanation of how it works at [0]. The vague notion of "patch commutation" is central to both operational CRDTs and Pijul's theory of patches, but other than that, I don't really see any similarities. [0]: https://jneem.github.io/merging/ https://jneem.github.io/merging/
pmeunier 6y ago
Pijul is a CRDT. The main new idea is that it the smallest generalisation of text files that is a CRDT while keeping important properties such as the relative order of parts of the file.

sally1620 6y ago

There are a lot of good VCS systems, but it seems like nothing can compete with Git in popularity.

theamk 6y ago
Well, it's hard to beat the combination of very simple data model and lots of convenient commands. The convenient commands means everyone has their own workflow. Someone might want to create "ideal commits" instantly. Someone else might interactive rebase all the time. Yet another person can cherry-pick. Or soft reset and re-commit. Keep few branches or many branches. Or do all the work one one personal branch and pick the relevant commits later. The simple data model means you don't have to understand what the other person did in order to work with their changes. You can work you way, they can work their way, but the commits are all the same. It is a tree of files with name and parents attached to it.

phreack 6y ago

I realize this is an old project and that it's not a big deal and that this may seem childish and many other disclaimers. But. Pija is a specific synonym for penis in many Spanish dialects, so this tool's name reads like Dickul in English, which is something I think the owners should be aware of if they're not already.

baq 6y ago
See also Coq, the theorem prover.
- AlexanderDhoore 6y ago
  Git also isn't a very nice word. https://www.merriam-webster.com/dictionary/git https://www.merriam-webster.com/dictionary/git
  - kkarakk 6y ago
    Git doesn't have sexual connotations. any term with sexual connotations is a hot potato nowadays in software biz/collaboration
    - PedroBatista 6y ago
      Everything is a hot potato when your basic needs are met and you’re bored and more importantly you desperately feel the need be “right” about something, perhaps listened.
mumblerino 6y ago
But Pija is not part of the name; Pij is. Italians use Fica for the female counterpart, and the national automobile company recently formed FCA. People joked about it and then everyone moved on.
igitur 6y ago
I think you'll struggle to find a human pronouncable 5 (or fewer) letter word that doesn't mean something nasty in some language.

ZuLuuuuuu 6y ago

Is Pijul something worth to look at if I am also interested in versioning binary file involving workflows? For example if I am an electronics engineer doing PCB design work? Or is it most suited for software projects with text based files?

howling 6y ago
Not an expert but I think it is only suitable for text file since most diff algorithms assume the files are made of not-very-long lines.
pmeunier 6y ago
It depends: the main issue is the diff algorithm. Pijul's diff is not line-based, but rather "byte block"-based (which at the moment happen to be lines). This means that we could totally imagine more clever diff algorithms for specific use cases. I don't know anything about PCB design files, but an example application of this is to treat indentation and spaces as their own blocks.

rkangel 6y ago

Pijul has come up a few times. Can someone help me answer the 'how would it help me' question? Under what real development scenario(s) would Pijul's approach help me?

chriswarbo 6y ago
It's a distributed version control system, implementing a sound mathematical model of software development (patch theory). In this sense pijul is like darcs, but it doesn't suffer from exponential-time edge cases when merging; hence it should be a pareto improvement. Of course, the elephant in the room is git: when git came out, most darcs users (eventually) switched over to it. Hence there's not many darcs users left for which pijul would be a no-brainer. There are many git users, most of whom have never used a patch-based DVCS, who would need a more compelling reason to switch. Personally, I'm glad the patch-based approach is still going, as it's always good to have competition. Plus, having a sound underlying model usually brings insights to a problem which aren't at all clear in more 'cobbled together' solutions like git (e.g. commutativity of patches is quite a natural property in darcs/pijul, which doesn't directly make sense in git due to its "commits" specifying their parents).
- JulianWasTaken 6y ago
  I haven't made up my own mind, and certainly intend to try this out. But I want to point out that your first paragraph offers no answer to the question, same as the title here doesn't. And I don't say that to be snarky -- what you list are implementation details, not an answer to the question. As a developer I don't care what kind of theory my program is built on I just want to know how it will save me time and give me new functionality. (In my spare time I can think the math is cool and be content with that). (Even more specifically -- git is a DVCS already, it's just most people seem to use it with a central server like GitHub, so personally I also didn't understand what the page meant when calling that one of pijul's advantages).
  - rkangel 6y ago
    In principle I do care about the fundamental model being correct - that can often bubble up to fewer (or cleaner) edge cases. Without help though, or many hours of usage I can't mentally map that model to what it is actually going to be like to use.

im3w1l 6y ago

The authors are obviously very proud of their clever algorithms, but as a user my main concern is not the implementation details. My main concern is what can this tool do for me? What are the new and amazing features I can use? Or which operations go faster?

faitswulff 6y ago

I happened to be looking around to see if there was a rust rewrite of rsync last night and stumbled across this post by the author of pijul that helps explain the benefits of pijul over git: > Git is great in many ways, but doesn't really know how to merge changes correctly. Even worse, it doesn't know how to "unmerge" changes. > It does try to merge branches, though, but doesn't give you any reliable guarantee on the result. For the unmerging part, it doesn't even try and you have to rebase your changes yourself, still without strong guarantees. > Pijul uses a patch algebra to do these things, where patches have several nice properties: > • Any two patches A and B either commute, or one of them explicitly references the other. This means that repositories behave as _sets of patches_ rather than as a linear history. > • Patches are associative: applying C on top of a repository that has A and B will yield the same result as applying B and then C on top of a repository that has A. Git could have this, but unfortunately, it doesn't. > • Patches have inverse patches. > We also have a sane internal representation of conflicts, so that all conflicts don't have to be solved immediately after merging. > I should add that Pijul is still quite unstable, and at this particular moment is in the middle of a giant protocol change. https://www.reddit.com/r/rust/comments/821sgo/announcing_rustsync_a_purerust_implementation_of/dv7cibj/ https://www.reddit.com/r/rust/comments/821sgo/announcing_rus...