1. 65
  1.  

  2. 18

    the user may specify extra, language-specific dependencies to model the edits more accurately, for example the dependency between introducing a function and using it in another file or another part of the same file.

    Wow. That’s the first time I’ve heard about this feature. That’s super interesting! I guess that relationship will have to be stored in the patch, then?

    1. 11

      Yes: in Pijul, dependencies are already stored in patches, and there is already a way to add them manually.

      1. 8

        FWIW, you might want a hat for making it clear when you talk from a position of authority about the subject.

        1. 3

          I’ve requseted one, thanks.

          1. 1

            That’s actually a really interesting feature. I never paid those hats much attention. I just assumed they were like user-set Reddit flairs.

          2. 3

            I really like the idea going somewhere behind current (D)VCS. The associativity is great. I would like to know how far your goals are. Are you going towards semantic diff/merge? Because some operations are not possible without having support for particular programming language or data format.

            With Pijul, developers can be 100% confident that the code they reviewed is the code that gets merged, which is not necessarily the case in Git and Mercurial.

            I am in doubt whether this is possible at all. If I want to be really sure, I have to do (a second) review after the merge. There are also cases where the merge runs flawlessly from the text/line point of view, but the result is wrong on the semantic level (two methods with same name/signature, two enum items with same value etc.)

            The question is whether these semantic operations belong to the VCS or should be done separately (and possibly on top of any VCS)…

            1. 4

              There are also cases where the merge runs flawlessly from the text/line point of view, but the result is wrong on the semantic level (two methods with same name/signature, two enum items with same value etc.)

              Sure, but at least with Pijul you can predict what the merge will be with absolute confidence. You can also be sure that merging changes one by one and all at once will yield the same.

              The question is whether these semantic operations belong to the VCS or should be done separately (and possibly on top of any VCS)…

              You can model dependencies between changes in Pijul, and one could totally imagine adding hooks to add dependencies.

            2. 2

              Are there any papers / specifications that you relied on for writing pijul that you could share? The ‘towards 1.0’ post gave a nice idea what is going on, and the posts on initialcommit are also nice but I’d also be interested in seeing some of the research underlying the design.

              1. 5

                It started with “A categorical theory of patches” (Mimram, Di Giusto), but there is a lot more in Pijul than just that paper. I still have to write the papers. I do have some of the proofs written up, but it’s not a paper yet.

                1. 2

                  Cool, eagerly awaiting the writeups, in the meanwhile there is the code :)

                  Thanks for all your hard work.

                  1. 1

                    Out of curiosity, do you know what the relationship is between academic papers and FOSS licenses? Theoretically, could someone read the papers you publish and then turn around and write an MIT-licensed DVCS similar to pijul?

                    To be clear, I have absolutely no interest (is negative interest a thing?) in doing so. I’m just wondering how academia views licensing and public information and what the standards are.

              2. 7

                This is really interesting. When using git I try to write small, atomic commits where each change is as small as possible and passes CI (and could be deployable to production without breaking anything). I feel like, with git, it takes a lot more effort to track dependencies between changes than it should and this kind of functional dependency tracking system would make it easier.

              3. 7

                I just wanted to say that this article was well-written. I had been meaning to learn about Pijul and this was a good starting point.

                Pedantic: I think there is a small typo where there should be a line-break before the pijul record command to separate it from pijul ls.

                1. 4

                  Thx very much! It was very fun to learn about Pijul and work on the article, so glad it was useful. The typo should be fixed as well ;)

                2. 6

                  from the pijul theory page:

                  Moreover, it is easy to show that Pijul implements a conflict-free replicated datatype (CRDT): indeed, we’re just adding vertices and edges to a graph, or mapping edge labels which we know exist because of dependencies. … Pijul’s datastructure models, in a conflict-free way, the conflicts that can happen over a text file

                  sounds cool, but I wonder how it handles binary files and I can’t seem to find the docs for that.

                  1. 4

                    From having played with the present version a little bit, my guess would be:

                    • the underlying library/model will be able to deal with binary files (and technically changes would be binary patches – replacing offset/length by offset/length)
                    • the pijul command probably isn’t aware of / doesn’t deal with binary files yet at all
                    • a naïve implementation of binary files could have changes that just say “replace complete contents by this”, which would yield a linear dependency chain of the history of the file (until you start merging, at which point you’d introduce a conflict-resovling change that chooses one of the two options)
                    1. 9

                      It does deal with binary changes, I even have a Pijul repository of music and movies on my hard drive. Obviously, this comes with some restrictions:

                      • We don’t have a good diff algorithm for binaries yet (but feel free to help us write one).
                      • Conflicts are handled poorly (conflict markers are printed to the file). We could do better, by the way, by writing different files.
                      • Pijul can’t print diffs on binary files in text mode (but that’s sort of expected, right?).
                      1. 4

                        See bsdiff1. FreeBSD does binary diffing and patching extraordinarily well. I’ve rolled my own binary diff in the past by using a rolling hash window across the two files to identify matching chunks across both. Simple and worked reasonably well. But for something proven, look at FreeBSD.

                  2. 6

                    I really like the content and layout of this article. I just wish I understood the differences between Pijul and Anu better. The https://anu.dev/ site seems to be just a Pijul website, actually. It’s confusing!

                    1. 15

                      We made an attempt at renaming, because many people were complaining about the name. Then, even more people complained about the new name, so we changed it back. Googlability is the main feature of that name.

                      1. 7

                        fwiw, i thought pijul was a good name.

                        1. 4

                          This is super sensible and super reasonable. Thanks for helping me to understand!

                      2. 3

                        In the linked history, the timeline starts with SCCS; However, I believe that PATCHY from CERN (that still exists!) is the first (1960s AFAIK).

                        1. 2

                          The linked VCS history articles claim to cover inner workings etc. — but I’m disappointed to find no mention of (CVS-related, I believe?..) in-source markers like this:

                          /* $Id: snprintf.c 927 2002-07-23 23:12:20Z strauss $ */
                          

                          Those who read the source I’m sure will recognize this, seen in many older pieces.

                          It’s still sort of a mystery to me. Can anyone explain what was it used for?

                          1. 4

                            RCS, which CVS was based on, would automatically expand certain variables – you would put $Id$ in a comment (or a perl string) and it would turn into something like that. It was … a feature.

                            I remember adding a line like global $VERSION = split("$Id")[2]; or whatever. It was handy, but hardly worth using CVS for.