Pijul: Towards 1.0 | Hacker News Reader

Pijul: Towards 1.0

pijul.org

165 pointslelf107 comments

I've been keeping an eye on Pijul for a while, but assumed that (when it eventually stabilised) it personally wouldn't be worth the effort to switch from git.

I've changed my mind now that they're tracking byte ranges instead of lines, with ranges decided in a customisable way at commit time. Semantic/format-aware versioning would be really nice. The easiest plugins to write would be s-expressions and JSON, and I could definitely see myself choosing Pijul for such repos in the future. If the patch-based approach is truly as nice as it appears, that might push me to use it more generally.

In fact, making an s-expression plugin which is robust across various Lisp dialects might be a good way to bootstrap the user community.

It would be nice to have for other languages too (C, Python, etc.), but they'd (a) be more complicated and (b) more subject to churn.

Encoding a generic, potentially versioned AST in S-expressions seems feasible.

I believe the Unison language [1] does this for their code storage system. (Unison does not use traditional text storage but stores code in a normalized repository)

[1] https://github.com/unisonweb/unison

There are multiple ways to do it, e.g. spreading data and parentheses across multiple lines to work better with line-based tools like git, or keeping revisions in the files themselves, etc. but most approaches require translation back and forth, which is a burden on those trying to handle the data (e.g. viewing diffs, bisecting to pin down a bug, etc.).

The Haskell DVC system that pijul "sort of" evolved from (theory of patches-wise mostly, just being careful given the stringent IP/credit language afoot), darcs, had this sort of semantic concept. It could track, e.g., symbol renames very early on in darcs' history. I haven't looked at darcs in many years, but it would be unsurprising if it had evolved to similar generality like pluggable byte ranges.

I'm the author, I understand how that comment of mine could be misinterpreted, which is why I removed it. It was just a reaction to a number of plagiarism events that have happened to me in recent years. At some point I've even been asked to review papers claiming to prove my own results.

No big deal from my perspective. I was just explaining my cautious wording. I know you've been open about working with/from "ideas/people" in the darcs community, and good about the shoulders [1] the pijul work stands on/improves, and I also dislike people not giving credit where it is due. Sometimes a few bad apples ruin many things. FWIW, I liked the name "Anu" better. :-/ EDIT: and thanks for all your hard work on Pijul!

[1] https://arxiv.org/abs/1311.3903

I explored this idea back in the day with darcs (though I don't think darcs' proposed character-based patch format "chunks" ever made it past the proposal stage), as some back and forth discussions led me to what I think is a perfect compromise on power, time (to compute), and universality.

I explored using an off the shelf syntax highlighting tokenizer (Pygments specifically as a it was a Python prototype) [1] to build character-based diffs. Got surprisingly good results from what I tested. Most off the shelf syntax highlighters support a huge variety of languages. One advantage to using a syntax highlighting tokenizer/lexer is that they are designed to be fast (many of them need to be real time in text editors after all), and handle "degenerate cases" very well (text editors spend a lot of time on work in progress code that doesn't fully describe a complete compilable unit; version control systems just as well need to be good at storing work in progress states).

The finished prototype I built created standard character-based unidiffs, and it sounds like could possibly be slotted directly into Pijul now. I'd be very interested to experiment further with it now that one of the patch algebra VCSes has finally adopted a "chunk" option.

[1] https://github.com/WorldMaker/tokdiff

(ETA: Suppose the first step is that it is time to get the band back together and update the prototype to Python 3.)

Very cool. I suppose these days tree-sitter would be one way to support a lot of languages at once ( https://tree-sitter.github.io/tree-sitter/#available-parsers )

Still a tiny fraction compared to available tokenizers in Pygments: https://pygments.org/languages/

(Or the vast number of TextMate grammars in the wild, such as editors like VS Code have standardized on.)

The "universality" of tokenizers is tough to beat, and though the tokenizers seem "dumber" than parser brethren, it's at a nice maxima for "good enough" for things like character-based diffs.

I love that.

> The finished prototype I built created standard character-based unidiffs, and it sounds like could possibly be slotted directly into Pijul now.

The diff algorithm, acting on lines, is pretty generic in Pijul, but there is a crucial and nontrivial pass after that, to get from a line diff to a graph diff.

Does that make working with it harder ? Can we still default to lines ? Am I misunderstanding ?

No. Yes. Not sure.

From my understanding of the post:

- Pijul patches were storing raw lines of text

- Word-based diffing was suggested as an option

- This option wasn't implemented due to complexity, and having to decide at repo creation time whether to store lines or words

- Unrelated improvements to Pijul's performance resulted in patches storing offsets into a byte array, rather than raw text

- Since offsets can point anywhere, patches are no longer limited to being line-based

Lines are still the default.

My idea that I’ve bandied about here a few times would be to create some kind of a semantic database (not based on relational algebra). All tooling could deal with this rather than the text of the source code.

Note that you could implement a Token or AST aware merging strategy for git as how you merge is an implementation detail that is not encoded into the repo.

Merging is only one aspect of version control. Also, merging (especially automatically) is limited by the quality of the data. For example, it's common for git to mix up function definitions by fixating on common lines (e.g. braces), e.g.

    -def foo()
    -{
    +def bar()
    +{
    +  doBarThing;
    -  doFooThing;
     }

There are many ways to represent the same diff, but this sort of half-and-half result happens so often, and is such a minor problem, that it's usually not worth bothering to fix when committing. Yet it's the sort of weird input that can complicate later merges, cherry-picking, etc.

A semantic-aware diff could do better. Again, there are many ways to represent the diff, but it could be as fine-grained as the token-level, e.g.

    def -foo+bar()
    {
      -doFooThing+doBarThing;
    }

Or as coarse-grained as the definition level, e.g.

    -def foo()
    -{
    -  doFooThing;
    -}
    +def bar()
    +{
    +  doBarThing;
    +}

Either way (or something in-between), these represent more meaningful changes, and hence provide more useful input to subsequent processing (e.g. merging).

I'm not sure what you mean. Git is snapshot based. There is nothing to fix when committing, you just commit the result of the merge. Any diff you see is just for display purposes or for input to the three-way merge algorithm. Other users might see a different result if they "git show" your commit if they have a different diff algorithm configured. Pijul is not immune from diff algorithm problems you are talking about except with Pijul it is part of the repo encoding unlike Git. IOW, git already has the freedom to use a merging strategy that understands tokens or AST since it is not hard-coded into the repo encoding.

I think this sounds nice but it feels difficult to me.

One property you might want would be that, in some sense, parentheses would always remain balanced. I think this would be very hard if not impossible to get from the graph-of-byte-ranges representation. But I’d be excited if someone figured out how to do it.

I think a particular part of the problem is to get the diff algorithm to match parentheses correctly. Consider some changes from A to B:

  1A (a b)
  1B (a b) (c d)
  
  2A (define p () (a) (b) (c))
  2B (define q () (a) (b)    ) (define q () (p) (c))

  3A (a b   c d)
  3B (a b) (c d)
  
  4A (a b   c  )
  4B (a b) (c d)
  
  5A (a b   c)
  5B (a b) (d)

I think in these examples it’s relatively easy to pair up parentheses in a reasonable way though there are already some tricky cases. As you get more of a tree structure and want a diff algorithm that can think of operations like wrapping, splitting, and spreading as basic operations as well as appending and deleting, I think it becomes even harder to make the right call. Indeed I think computing this kind of diff of s-expressions is computationally a harder search problem than diffing files.

I think it's awesome that people are doing research in the area of version control systems. Even though Git is already pretty great in my opinion, there's always stuff that can be done better. I would love to see what the future holds!

Anyway, what I find weird about the Pijul project is that they place the barrier to entry so damn high, that it's absolutely not motivating to even give it a try:

- The Pijul front page (https://pijul.org) has a prominent link in the middle that points to their source code hosting service, Nest. That page has always been dog slow. It takes multiple seconds for that page to open, and then it shows me "Not found". Maybe I should log in to view the code? There is a "Sign in" form at the top right of the page, so maybe I should do that. Where's the registration button?

- The project got renamed to Anu. A couple of days ago I tried to visit that page (https://anu.dev), and I wasn't able to find any source code there. I just tried to go there again and the page is offline.

- As BlackFingolfin pointed out, the blog post has a "Warning about licenses" at the top. Even though I don't think that's how the GNU GPL works, it's already a big motivator for me to simply close that tab. I do work in the area of data storage myself. Would I want to put myself at legal risk, just because I want to try an experimental VCS?

- Why isn't there an official Git mirror of Pijul/Any? Sure, it's awesome if those tools can host themselves, but what about being able to set it up quickly? Pijul/Any is written in Rust. Doesn't Cargo depend on being able to 'git clone' software for it to be installable?

I slowly get the feeling that the goal of the Pijul project was never to become popular in any way. To me it seems little more than a hobby project of someone with an interest in version control systems. That's fine I suppose, but my fear is that this current approach is that the existence of this project simply acts as an impediment for truly motivated people to work on the next generation VCS.

> Doesn't Cargo depend on being able to 'git clone' software for it to be installable?

No. The registry is controlled using git, and Cargo allows you to pull in software via git, but Rust projects don't need to be using git.

To be a little more explicit about it:

* The index of packages on crates.io is stored in a git repository

* Cargo knows how to clone that down without you having git installed

* The contents of packages are not acquired by doing a git clone; source code is stored in an S3 bucket, and Cargo downloads it directly.

* You can have your project depend on a package that lives in a git repository, but you cannot upload a crate to crates.io that depends on a git repository. This means that this feature is mostly useful for end projects and private libraries, not public dependencies.

> - The Pijul front page (https://pijul.org) has a prominent link in the middle that points to their source code hosting service, Nest. That page has always been dog slow. It takes multiple seconds for that page to open, and then it shows me "Not found". Maybe I should log in to view the code? There is a "Sign in" form at the top right of the page, so maybe I should do that. Where's the registration button?

The Nest is still experimental (which explains the downtime), but you shouldn't need to sign in order to view any code there.

> - The project got renamed to Anu. A couple of days ago I tried to visit that page (https://anu.dev), and I wasn't able to find any source code there. I just tried to go there again and the page is offline.

Right, there have been really strong reactions against that move. As a person who carefully listens to HackerNews and Twitter comments for life advice (as one should), I decided to revert that move.

More seriously, I noticed it was distracting from the main point. But then I managed to find another distracting thing, by writing a rant about occurrences of plagiarism that have happened to me, including theft of actual GPL source code, as well as republication of academic papers (in one case, I was fortunate enough to be picked for review).

> - As BlackFingolfin pointed out, the blog post has a "Warning about licenses" at the top. Even though I don't think that's how the GNU GPL works, it's already a big motivator for me to simply close that tab. I do work in the area of data storage myself. Would I want to put myself at legal risk, just because I want to try an experimental VCS?

That is clearly not what I meant, and I'm deeply sorry about this.

> - Why isn't there an official Git mirror of Pijul/Any? Sure, it's awesome if those tools can host themselves, but what about being able to set it up quickly? Pijul/Any is written in Rust. Doesn't Cargo depend on being able to 'git clone' software for it to be installable?

Until there are packages in linux distributions, you can get it with `cargo install pijul --version 1.0.0-alpha`. You would need cargo to compile it from source anyway.

I'm really excited to see what Pijul ends up doing. I do love git, and I think its simple mental model of content addressed commits and trees is fantastic. However I do often find myself annoyed by the lack of a "change" concept other than the immutable commit. It seems that this results in review tools bending backwards to add that on top and it makes backports and other cherry-picks harder to follow.

One of the show-stopper complaints that I had about Pijul was the lack of a version identifier. However according to this post that has now been resolved which is fantastic news.

> Therefore, if after reading this post, you independently rediscover the algorithms presented here, that’s ok, but you must still license your “independent rediscovery” under the Gnu GPL-2.0 license, and cite the sources (for instance this post). This also applies if that rediscovery happens in the future, including in zero, one or more years.

That's not how copyrights work.

Yeah, they are basically claiming patents on the ideas presented. Not my cup of tea either.

I'd love to give it a try again the latest (v0.12.2) release, but:

     no matching package named `sequoia-rfc2822` found

and I cannot download the latest sources because I'm not "lucky enough to already have one version of Pijul" sitting around to access the self-hosted repo.

I clicked on the "nest" link (hoping for a download source tarball button), but this link 404s: https://nest.pijul.com/pijul_org/pijul

Possibly this is the right home for pijul: https://nest.pijul.com/pijul/pijul

(no download functionality sadly)

I cannot find an issue tracker. Hoping the author reads this. The project seems very interesting

Install with:

> cargo install pijul --version 1.0.0-alpha

(needs some native dependencies like zstd)

Seems like the project was renamed to `anu`, and then back to pijul, and all documentation and hosting is a big mess right now.

> I cannot find an issue tracker. Hoping the author reads this. The project seems very interesting

https://nest.pijul.com/pijul/pijul/discussions/new

Has any1 had success compiling it on mac? I get a link error involving libclang.

      thread 'main' panicked at 'Unable to find libclang: "the `libclang` shared library at /usr/local/opt/llvm/lib/libclang.dylib could not be opened: dlopen(/usr/local/opt/llvm/lib/libclang.dylib, 2): Symbol not found: __ZN4llvm11raw_ostream10resetColorEv\n  Referenced from: /usr/local/opt/llvm/lib/libclang.dylib\n  Expected in: /Users/erin/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/libLLVM.dylib\n in /usr/local/opt/llvm/lib/libclang.dylib"', /Users/erin/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.55.1/src/lib.rs:1896:31

That's from doing "cargo install pijul --version 1.0.0-alpha".

Bonus question: I'v never seen the notation "[0,n[" to represent a half-open internval before (I've seen "[0,n)"), but it does have a certain logic to it! Is it novel or standard in some places?

Yes, it's standard in France at least.

Actually, both notations are described by an international standard, according to Wikipedia [1]

[1]: https://en.wikipedia.org/wiki/Interval_(mathematics)

Very interesting! I'm surprised I've never encountered it before.

Thanks for Pijul; I'm super-excited about the possibilities. (Unlike many HN commentators, who are too trapped inside the git way of thinking to realize its limitations ;-)

I think your biggest challenge now is going to be everything besides the software itself that makes a project successful: Is the website fast and inviting? Is the software easy to install? Etc.

Thanks again & wishing the best for Pijul.

> Is the website fast and inviting? Is the software easy to install? Etc.

A very gentle way of phrasing this ;-) Thank you.

The Nest used to be really fast with the previous Pijul, but I remember the first iteration took a few days of debugging under full load before being stable. I'm not expecting it to be fast until a week or two.

https://discourse.pijul.org/t/build-failure-on-macos-zstd-se...

It looks like you don't have libclang. The required libraries are openssl libsodium llvm(which contains libclang) xxHash zlib zstd libgit2 pkgconfig

edit: with nix on macos, this 'should' be enough

   $ nix-shell -p openssl libsodium llvmPackages.libclang xxHash zlib zstd libgit2 pkgconfig rustc rustfmt cargo darwin.apple_sdk.frameworks.CoreServices darwin.apple_sdk.frameworks.Security darwin.apple_sdk.frameworks.SystemConfiguration
   [nix-shell] $ cargo install pijul --version 1.0.0-alpha --features git

Well, I think I have it installed (via brew), and the .dylib exists, it's just that doesn't have the spcific mangled symbol Rust is looking for inside the library. Feels like a version mismatch or something.

Edit: The nix tip worked; thanks!

I've been meaning to try out nix for a while anyway, so this was a nice nudge. :-)

The notation [0, n[ is standard in Germany.

> All the above has been complicated by the fact that I accepted an academic job in August 2018, only to be told, after I had resigned from my previous job at Inria and moved to another country, that I wouldn’t be allowed to work on my own research projects (including Pijul), or at least that the legal status of that work outside of my holidays was unclear.

What's going on there? Sounds like a hostile environment!

> One common criticism we’ve heard since we started Pijul a few years ago was about the name. I came up with that name, but to be honest, I was more interested in getting stuff to work (which was challenging enough) than in thinking about names at that time.

Can someone help me find a more flattering way to pronounce this project? Any way I slice it it sounds awful in English.

    - PEE - HOOL
    - PEE - HOLE
    - PIE - HOLE
    - PEE - JEWEL
    - PIE - JEWEL

Hearing nothing, probably gonna have to stick with "pie jewel".

The author seems to be referencing a project of theirs with a Finnish name, so perhaps my intuition as a native Finnish speaker can help. In Finnish you’d likely pronounce pijul [pi-jul]. If I were to pronounce the word ”in English” starting from that basis, the smallest change is, I think, to make it [pi-zhul]. That is, ”pee-jewel” but with short vocals instead of long ones for both words.

Without reference to the source language, the most native rendering of this based on spelling definitely has short vowel sounds. It takes the vowel sounds of “sit ghoul”

I looked into Pijul in the past but in the end the model seemed worse than git to me.

Git is a snapshot based model and so doesn't leak any implementation details about patches themselves. Every user can use whatever diffing algorithm they want when generating patches for use in three way merge and then only the results are stored. In fact with git you don't even need to use three way merge, the only thing that matters is that you say "I merged A and B and this is what the tree looks like as a result".

Pijul being based on patches encodes patch information into the repo. Each line belongs to a patch and it can depend on the diffing algorithm which patch owns a particular line. This is a big drawback and so we should hope to get some serious benefits to make up for it, but I don't think we do.

One of Pijul's main selling points is the ease of cherry-picking. They make the claim that cherry picking "just works" but I think this misses the big picture. Pijul's cherry picking only "just works" with respect to merging lines of code. It can automatically pull in patches that the lines of code you are merging depend on for the merging algorithm, but it can not track things like "This calls a function introduced in patch X" which makes the cherry-picking functionality of very little value.

The biggest problem IMO is that Pijul is more similar to git rebase than git merge. What I mean is that it forces you to resolve conflicts that you probably wont ever care about. Let's say I have a local git branch with 10 commits on top of master. Now if I update my master and do "git rebase master" I must make sure that each one of those 10 commits resolves cleanly on top of the new master. It's common to get into situations where you would have to resolve conflicts in several of those rebase steps but a merge which did a three way merge of the tops of both branches would result in few or no conflicts. Pijul is like rebase in that it forces you to consider the full history of all the patches in a set which requires to resolve arbitrary conflicts. The benefit of resolving those conflicts is that it can help with cherry-picking, but I don't want to be doing this work all the time for an incomplete solution to a rare operation. I even made some test repos in both Git and Pijul to verify that Pijul forces you to resolve conflicts that three-way merge doesn't care about.

It's certainly possibly I got some information wrong about Pijul. Please correct me if I have!

> It's certainly possibly I got some information wrong about Pijul. Please correct me if I have!

That's actually the case, because you can totally simulate Git using Pijul if you want, except for the weird merges where Git shuffles up lines randomly.

> This is a big drawback and so we should hope to get some serious benefits to make up for it.

It is not a drawback at all, there are no downsides to it, and we get the very serious benefit that merges are associative, which is not the case in Git. Indeed, in Git (using diff3 to merge), when Alice adds lines at the beginning of a file and Bob adds lines at the end, some of Bob's line can get merged into Alice's new lines.

> it can not track things like "This calls a function introduced in patch X" which makes the cherry-picking functionality of very little value.

You can totally do that in Pijul by adding extra dependencies, and moreover, this is like saying `git rebase` adds very little value to Git.

> Pijul is like rebase in that it forces you to consider the full history of all the patches in a set which requires to resolve arbitrary conflicts

It is actually the exact opposite: Git forces you to reconsider those conflicts (there's even `git rerere`), whereas Pijul only shows you the unresolved conflicts. Once a conflict is solved in Pijul, it's solved by a patch, and solved forever.

> That's actually the case, because you can totally simulate Git using Pijul if you want, except for the weird merges where Git shuffles up lines randomly.

I don't think this is true. The snapshot model is fundamentally different and doesn't require resolving conflicts in the same way.

> It is not a drawback at all, there are no downsides to it

It's a much more complicated model to implement, performance isn't as good, and your model is closely tied to your diffing algorithm. Contrast this to git where you can merge however you want and no one else needs to know the details.

> You can totally do that in Pijul by adding extra dependencies, and moreover, this is like saying `git rebase` adds very little value to Git.

Can do that and will happen in practice are very different things. It's not something likely possible to do automatically and doing it manually is just extra work that is probably for nothing.

> It is actually the exact opposite: Git forces you to reconsider those conflicts (there's even `git rerere`), whereas Pijul only shows you the unresolved conflicts. Once a conflict is solved in Pijul, it's solved by a patch, and solved forever.

I'm comparing git merge to adding a patch to a set in Pijul.

Let's say I have a patch A that adds a line: return 1 + 1 + 1 + 1;

and a patch B based upon A changes it to: return 1 + 1 + 2;

and a patch C based upon B changes that to: return 1 + 3;

and a patch D based upon the original A changes it to: return 4;

So we now have:

  A
  |\
  B D
  |
  C

Now lets say we add them all to the same set of patches. Will I have to resolve the conflict in B and D and then also the conflict in (the resolution of B and D) and C?

Alright, maybe you should have read my answer before replying. I do know what I'm talking about, I wrote the damn thing.

Which part of my reply do you object to? Maybe you object to my first sentence but I am trying to make sure my understanding is correct with the scanario I laid out at the end. Would that require 1 or 2 conflict resolutions? I actually tried to use Pijul directly to see what would happen but I couldn't figure out how to do it with the 1.0 alpha. I thought I'd use branches or unrecord to simulate the scenario I laid out but I could only figure out how to create branches but not switch between them (the checkout command seems to have been removed) and unrecord seemed to not only not revert files to their former state but I could not reapply the patches later with pijul apply. Also all documentation is 404. The non-alpha version of Pijul was uninstallable through cargo and the snap version segfaulted when trying to record. I really have invested time into this to try to get a proper understanding.

Pijul is better than anu (means b*hole in Latin languages) but still a terrible name.

The funny thing about names is whatever they are, you end up getting used to them. I remember when the iPad first came out the whole internet was going on about what a terrible name it was. Now it seems completely natural. Pijul is similar: perhaps odd at first, but I think it'll do fine in the long run.

I do think they might want to go with something shorter (pi?) for the command-line.

In my youth, I wrote an impassioned letter to Nintendo to not name their console the Wii. It went on to be a best seller.

Now "git," "pijul," and "anu." I guess it doesn't matter as long as it works /shrug

Ah yes, the eternal challenge of "Naming things".

I just hope the command line tool gets a good 3-letter binary, "pijul record" is a bit awkward, maybe "pjl"?

And distribute that by default as well, otherwise everyone defines their own mutually incompatible aliases.

Oh and provide an official way to pronounce it!

I predict that once it gets popular, in common usage it will be shortened to 'pij' (and derivatives).

EDIT : Oh crap : https://en.wikipedia.org/wiki/Islamic_Jihad_Movement_in_Pale...

Well, at least it didn't change the name to another (than 'Anu') ancient god : Isis !

Do you know, that calling someone a git is an insult?

Considering how much time one spends swearing while trying to resolve issues with version control, I think git is far too nice a name.

git

/ɡɪt/

nouninformal•derogatory

noun: git; plural noun: gits

    an unpleasant or contemptible person.
    "that mean old git"

But that was rather the point: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'" https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27Git....

I guess that the author might be an astronomy aficionado ?

https://www.youtube.com/watch?v=OSWszdSHkyE

Git could learn from Pijul, IMHO, in the sense of better emphasis for newcomers for how to think in terms of patches.

For example Pijul aims to focus on first creating a patch, whereas git tutorials IME tend to focus on first creating a branch, then editing files, and only later discussing patch oriented areas such as `git add --patch` and `git stash`. I see many newcomers finally get their "AHA" insights about git's power when they learn `--patch`.

I haven’t met a single person that used manual git patches in my entire career (10+ years, web services).

I've met a lot of people that would use it if they knew how. (It's so very common to work on things side-by-side and then want to split things out into more logical commits to describe things as individual changes.)

Coming from a darcs background where that was a natural and very easy part of the UX, I had reason to learn how to do it in git (because I was used to doing it quite often in darcs). When people watch me do it, they can't believe that magic exists in git.

I agree with the above poster that if graphical user interfaces prioritized it better, if the CLI had a bit fewer warts (I still often confuse when to use `git add --patch` and when to use `git add --interactive` though it isn't an awful confusion because you can get to one from the other when you remember how to use it), and if tutorials tried better to train people on the tools that already exist, a lot more people would presumably use them (daily in some cases). More awareness of tools like darcs and pijul does help in that by presenting UXes built around it, it does drive people to ask how to do equivalents in git.

(Why just the other week there was an HN headline where someone was really excited they hacked the email-focused `git format-patch` and a workflow akin to sending email to oneself to replicate `git add --patch` because they didn't realize `git add --patch` was also a built-in tool.)

Just wanted to say that the Magit UI makes it really easy to pick and choose which lines to commit (plus it has code-folding for files and chunks, which is nice).

I still drop into the git CLI if I need to do things like editing the contents of lines, e.g. if I've added a new function and renamed an existing one, and I want to add these as two commits, I might edit the first commit to use the old name.

One great use-case for git patches is moving files between repos without losing their history. I've done this many times, e.g. solving a problem in an application, then later wanting to move that code into a library so it can be used elsewhere.

I do this so infrequently that I never remember the commands, but frequently enough that I remember which StackOverflow answer to Google for: https://stackoverflow.com/a/11426261/884682

really, really excited for this. i’ve had my eye on this project for a few years, though only from the sidelines, but now’s the time to truly take the dive! :)

Documentation is 404:

https://pijul.org/manual

Same for their repository linked from the main page: https://nest.pijul.com/pijul_org/pijul

I think you’ll find it under https://nest.pijul.com/pijul/pijul

Work in progress. Days have 24 hours, projects only move one step at a time.

>projects only move one step at a time.

That's not a good vision for the future ;)

BTW, my Day has max 18-20 hours.

But don't be angry, i just wanted to play a little bit quality assurance...and read the documentation.

my day has max 1-2...

I'm not angry at all! It is exciting that people are interested in this work.

Any project moves one step at a time, even though the length of time steps might step down over time.

I’m confused. Is this project still going or is Anu the future?

At the end of the article it says that the rename (to Anu) has been reverted. The project is called Pijul again.

Ahh thanks

ATM don't have time to read in depth but can someone explain if Pijul allows a user to checkout a subset of changes (say I only checkout one folder or a file)?

Yes, it does, even if the interface might be somewhat lacking, and the documentation work in progress. Pijul can even postpone downloading content that has been deleted since a change was created.

More detail in that blog post, when you have time.

IMO that could be a great selling point if this works even remotely like SVN partial checkout.

Big problem on Git in game dev, is the fact that you often don't want to download everything. And then you have to use subtree and submodules... And that's a nightmare.

I gave up half way through the copywrite claim crap, didn't want or need to know anything more...

Honestly, the whole faffing around with the name leaves me with a very bad taste in my mouth.

There’s no way I’m ever going to be typing pujil, no wait pijul, any amount of times during my daily work.

Anu was at least pronounceable without doing a few double takes.

It's a lot of characters to type all on the right hand (in QWERTY). I suspect most people would alias it to `pj`.

Hm, right at the start in the "Warning about licenses" they seem to try to make the GPL apply to a concept, an abstract algorithm -- kinda like a patent? But I don't think that's how licenses like the GPL work? And hence that this is not legally binding in any way? At the very least, it reads rather strangely to me. Perhaps someone who knows more about licensing that me can elaborate?

To clarify: they claim that after reading the article, any independent implementation of the algorithm (even if it didn't involve looking at their code) must be licensed under the GPL. But that seems to go against everything I thought I knew about "clean room reverse engineering"?

I also came here to comment on this. A quick search seems to indicate that algorithms cannot be copyrighted, only an "expressed representation of a work" can be copyrighted. So if you represent the algorithm as (pseudo)code, this representation is copyrighted, but there is nothing to stop someone from reimplementing it in a non-verbatim fashion.

That said I couldn't find anything authoritative like case law or guidance from WIPO or other IP organisations, so any expert input would be appreciated in this thread.

https://law.stackexchange.com/questions/4097/does-copyrighte...

What they're looking for is a patent, not copyright.

It made me stop reading the rest. True or not, I will not further investigate what Pijul is. Negative Marketing.

You should read the other comments made after yours... apparently that was just a misunderstanding and not what the author intended.

The author discusses it on Twitter: https://twitter.com/nuempe/status/1325756834947461120

Quoting:

> Well, this is the documentation for a particular implementation. It is actually targeted at a particular species of academics, who have been quietly republishing my work in recent years, and not only my work on Pijul.

Edit: Author has removed the licensing claim so we can put this thread to rest. The original comment follows.

---

This is absolutely bogus. TFA is a description of the math behind Pijul, not a step by step description of the implementation, and certainly not the implementation itself. Have you ever read a math/CS paper that attempts to dictate a license on all future work based on the algorithms (or ideas in general) within? I’m honestly shocked that the author, who is apparently an academic, flouts academic norms like this.

Disclosure: as someone who was trained as a mathematician, I’m offended by attempts at restricting the free exchange of knowledge.

Re sibling that links to author’s tweet: plagiarism is something else entirely, and I fail to see how GPL helps in combating plagiarism.

> Have you ever read a math/CS paper that attempts to dictate a license on all future work based on the algorithms

That's a patent, and I do think that there exists papers that describes patented algorithms.

TFA seems to think that their algorithms is patented by the GPL license

Yes, that’s a subtlety that my original comment didn’t address.

However, even patents can’t be licensed in perpetuity, so they can’t possibly apply to all future work. GPL on the other hand doesn’t have an expiry date.

In addition, there’s no implicit patent, you have to apply in every jurisdiction where you want to protect your idea, and IIRC in most jurisdictions you either can’t retroactively apply for a patent after you’ve published the idea, or you only have a short period after publishing before the right is forfeited.

> GPL on the other hand doesn’t have an expiry date.

Of course it does. 70 years (or was it 95?) after the death of the author, like for any copyrighted work.

Their claim is simply incorrect. Copyright does not protect ideas. Claiming that they can infect ideas with the GPL is bizarre and deceptive bullying.

See tompazourek's message for quote or visit: https://twitter.com/nuempe/status/1325756834947461120

I think, it's less this, and more preventing others as passing these ideas as their own. Which is valid. I've seen sleazier academics just CnP things without attribution.

I'm the author. I've been asked to review results of mine in the past, taken form arxiv.org and resubmitted by senior academics. I've also seen partial reimplementations of Pijul, from the source code, with a different license, which is absolutely clear.

I've heard of cases where people just ripped off parts of another's work as PHD. I've never heard of someone submitting stolen work to a fellow he stole the work from. That's some A level chicanery.

> someone submitting stolen work to a fellow he stole the work from

When you submit a paper to a journal, you don't get to pick your reviewers. In fact, you most likely don't ever get to know who the reviewers are because the process is anonymized.

But given that many areas of scientific inquiry are highly specialized, it isn't particularly surprising that if you rip off someone's work, that someone is going to be picked as a reviewer for your paper by chance.

I'm sorry to hear that, but making false and intimidating claims about copyright doesn't help your situation.

The context and motivation are irrelevant. As a statement of fact the claim is simply false.

I'm the author, and I'm entirely guilty of that misunderstanding. This is not what I meant, it's just a commented targeted at a number of different people who have stolen my stuff in recent years, in different areas of my work, and not only about Pijul, genuinely claiming to rediscover it after they had read the code, read the papers, asked me questions about it.

That comment of mine doesn't belong in that post, I removed it.

It sounds like this is a (very common) mix up of copyright and plagiarism.

Whenever I've talked about Creative Commons with artists, their most frequent concern is about others passing off work as their own. It's a widespread conflation, but thankfully it's easy to sort out; for example, The Canterbury Tales was written before copyright existed, but that doesn't mean I can claim it as my own work; that would be fraud (specifically: plagiarism).

Thank you for clarifying this, I think it's much better if this paragraph doesn't distract people from the great work you are doing on Pijul. And being plagiarized totally sucks, as someone who has found his own GPL'ed code in non-open commercial products, I think I can relate, even though this is of course not quite the same. I hope you can find other ways to deal with that, though.

FYI the Documentation link [1] in the header menu of your home page is returning a 404.

[1] https://pijul.org/manual

This is intended as the docs for the new Pijul still have to be written and keeping up the old ones would have likely lead to confusion.

The gpl doesnt protect ideas, it only protects code. I agree that there is rampant theft going on in open source. You should keep your work closed source and figure out a way to prevent others from stealing your work from you before making it open source

Thrussh -- they remake ssh, but they never say why. They only say that it is difficult because of all the interoperability issues they keep discovering.

Ssh has such a large surface, I don't see why they would do this. I also hope they allow you to use openssh as a fall back.

I'm not sure why it would even use SSH instead of SSL/TLS.

Authentication.

Ssh deals with keys and accounts and all that which SSL/TLS don't do.

TLS has client certificates, and I actually have used them for authentication before.

Sure, but then you can't use your existing ssh credentials. And need to have a custom server and protocol.

And being able to use pijul (or git) over plain old ssh is a pretty nice feature.

First reason: writing servers that are easy to secure and maintain.

Second reason: SSH on Windows used to be the most nightmarish thing you can imagine.

Thrussh is not a "remake" of a ssh, it is simply yet another implementation, and I don't find that particularly unusual or problematic; if one is working on a Rust based project, IMO it makes a lot of sense to work on a Rust based SSH implementation, too (for all kinds of reasons, ease of use and portability being one).

As a matter of fact there are dozens if not hundreds of them out there. For a time, I was tracking some of them to figure out which ones support which particular protocol extension; the result is https://ssh-comparison.quendi.de and the list there is really incomplete (and sadly also outdated -- PRs welcome ;-)), I think I could easily double the number of entries there if I resumed work on it.

The one concern I'd have for a custom implementation is when they roll their own crypto... On a quick glance, that seems (?) to be the case here, see <https://docs.rs/crate/thrussh/0.28.0/source/src/cipher/chach...>, albeit only for chacha20poly1305 which is relatively easy to implement "right" and "securely", but one can still mess that up...

> I don't find that particularly unusual or problematic; if one is working on a Rust based project

I'm the author, and you just made my day. Thanks.

> On a quick glance, that seems (?) to be the case here

Nope, I don't do crypto, I wouldn't work on other stuff if I did.

That particular file you point to implements decoding from SSH packets, and passes everything on to libsodium.

Reply on news.ycombinator.com