22 ms·

Pijul: Towards 1.0

165 points by lelf 6y ago

nix23 6y ago
Documentation is 404: https://pijul.org/manual https://pijul.org/manual
- Semaphor 6y ago
  Same for their repository linked from the main page: https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul
  - dan-robertson 6y ago
    I think you’ll find it under https://nest.pijul.com/pijul/pijul https://nest.pijul.com/pijul/pijul
- pmeunier 6y ago
  Work in progress. Days have 24 hours, projects only move one step at a time.
  - nix23 6y ago
    >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.
    - baq 6y ago
      my day has max 1-2...
    - pmeunier 6y ago
      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.
BlackFingolfin 6y ago
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"?
- roca 6y ago
  Their claim is simply incorrect. Copyright does not protect ideas. Claiming that they can infect ideas with the GPL is bizarre and deceptive bullying.
  - Ygg2 6y ago
    See tompazourek's message for quote or visit: https://twitter.com/nuempe/status/1325756834947461120 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.
    - pmeunier 6y ago
      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.
      - Ygg2 6y ago
        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.
deleted 6y ago
[deleted]
garmaine 6y ago
> 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.
- nezirus 6y ago
  Yeah, they are basically claiming patents on the ideas presented. Not my cup of tea either.
EdSchouten 6y ago
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 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 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.
- richardwhiuk 6y ago
  > 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.
  - steveklabnik 6y ago
    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.
georgyo 6y ago
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.
- CodesInChaos 6y ago
  I'm not sure why it would even use SSH instead of SSL/TLS.
  - exDM69 6y ago
    Authentication. Ssh deals with keys and accounts and all that which SSL/TLS don't do.
    - jcranmer 6y ago
      TLS has client certificates, and I actually have used them for authentication before.
      - exDM69 6y ago
        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.
- pmeunier 6y ago
  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.
- BlackFingolfin 6y ago
  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 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/chacha20poly1305.rs 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...
ithkuil 6y ago
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 https://nest.pijul.com/pijul_org/pijul Possibly this is the right home for pijul: https://nest.pijul.com/pijul/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
- the_duke 6y ago
  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.
- pmeunier 6y ago
  > I cannot find an issue tracker. Hoping the author reads this. The project seems very interesting https://nest.pijul.com/pijul/pijul/discussions/new https://nest.pijul.com/pijul/pijul/discussions/new
jph 6y ago
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`.
- jiofih 6y ago
  I haven’t met a single person that used manual git patches in my entire career (10+ years, web services).
  - WorldMaker 6y ago
    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.)
    - chriswarbo 6y ago
      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.
kevincox 6y ago
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.
gigatexal 6y ago
I’m confused. Is this project still going or is Anu the future?
- chriswarbo 6y ago
  At the end of the article it says that the rename (to Anu) has been reverted. The project is called Pijul again.
  - gigatexal 6y ago
    Ahh thanks
- deleted 6y ago
  [deleted]
fattybob 6y ago
I gave up half way through the copywrite claim crap, didn't want or need to know anything more...
Aeolun 6y ago
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.
- philsnow 6y ago
  It's a lot of characters to type all on the right hand (in QWERTY). I suspect most people would alias it to `pj`.
chriswarbo 6y ago
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.
- the_duke 6y ago
  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 https://github.com/unisonweb/unison
  - chriswarbo 6y ago
    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.).
- cb321 6y ago
  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.
Ygg2 6y ago
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)?
- pmeunier 6y ago
  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.
  - Ygg2 6y ago
    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.
    - deleted 6y ago
      [deleted]
jiofih 6y ago
Pijul is better than anu (means b*hole in Latin languages) but still a terrible name.
- dilap 6y ago
  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.
  - faitswulff 6y ago
    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
- zeotroph 6y ago
  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!
  - BlueTemplar 6y ago
    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_Palestine 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 !
- scns 6y ago
  Do you know, that calling someone a git is an insult?
dilap 6y ago
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?
- Phlogistique 6y ago
  Yes, it's standard in France at least.
  - Phlogistique 6y ago
    Actually, both notations are described by an international standard, according to Wikipedia [1] [1]: https://en.wikipedia.org/wiki/Interval_(mathematics) https://en.wikipedia.org/wiki/Interval_(mathematics)
  - dilap 6y ago
    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.
    - pmeunier 6y ago
      > 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.
keeganpoppen 6y ago
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! :)
waterofclear 6y ago
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!
- pmeunier 6y ago
  > 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.
jhoechtl 6y ago
> 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!
djhaskin987 6y ago
> 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".
- Ezku 6y ago
  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.
- theonemind 6y ago
  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”
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]

Pijul: Towards 1.0

165 points by lelf 6y ago

nix23 6y ago

Documentation is 404: https://pijul.org/manual https://pijul.org/manual

Semaphor 6y ago
Same for their repository linked from the main page: https://nest.pijul.com/pijul_org/pijul https://nest.pijul.com/pijul_org/pijul
- dan-robertson 6y ago
  I think you’ll find it under https://nest.pijul.com/pijul/pijul https://nest.pijul.com/pijul/pijul
pmeunier 6y ago
Work in progress. Days have 24 hours, projects only move one step at a time.
- nix23 6y ago
  >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.
  - baq 6y ago
    my day has max 1-2...
  - pmeunier 6y ago
    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.

BlackFingolfin 6y ago

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"?

roca 6y ago
Their claim is simply incorrect. Copyright does not protect ideas. Claiming that they can infect ideas with the GPL is bizarre and deceptive bullying.
- Ygg2 6y ago
  See tompazourek's message for quote or visit: https://twitter.com/nuempe/status/1325756834947461120 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.
  - pmeunier 6y ago
    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.
    - Ygg2 6y ago
      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.

deleted 6y ago

[deleted]

garmaine 6y ago

> 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.

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

EdSchouten 6y ago

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 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 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.

richardwhiuk 6y ago
> 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.
- steveklabnik 6y ago
  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.

georgyo 6y ago

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.

CodesInChaos 6y ago
I'm not sure why it would even use SSH instead of SSL/TLS.
- exDM69 6y ago
  Authentication. Ssh deals with keys and accounts and all that which SSL/TLS don't do.
  - jcranmer 6y ago
    TLS has client certificates, and I actually have used them for authentication before.
    - exDM69 6y ago
      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.
pmeunier 6y ago
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.
BlackFingolfin 6y ago
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 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/chacha20poly1305.rs 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...

ithkuil 6y ago

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 https://nest.pijul.com/pijul_org/pijul Possibly this is the right home for pijul: https://nest.pijul.com/pijul/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

the_duke 6y ago
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.
pmeunier 6y ago
> I cannot find an issue tracker. Hoping the author reads this. The project seems very interesting https://nest.pijul.com/pijul/pijul/discussions/new https://nest.pijul.com/pijul/pijul/discussions/new

jph 6y ago

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`.

jiofih 6y ago
I haven’t met a single person that used manual git patches in my entire career (10+ years, web services).
- WorldMaker 6y ago
  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.)
  - chriswarbo 6y ago
    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.

kevincox 6y ago

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.

gigatexal 6y ago

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

chriswarbo 6y ago
At the end of the article it says that the rename (to Anu) has been reverted. The project is called Pijul again.
- gigatexal 6y ago
  Ahh thanks
deleted 6y ago
[deleted]

fattybob 6y ago

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

Aeolun 6y ago

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.

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

chriswarbo 6y ago

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.

the_duke 6y ago
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 https://github.com/unisonweb/unison
- chriswarbo 6y ago
  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.).
cb321 6y ago
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.

Ygg2 6y ago

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)?

pmeunier 6y ago
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.
- Ygg2 6y ago
  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.
  - deleted 6y ago
    [deleted]

jiofih 6y ago

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

dilap 6y ago
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.
- faitswulff 6y ago
  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
zeotroph 6y ago
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!
- BlueTemplar 6y ago
  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_Palestine 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 !
scns 6y ago
Do you know, that calling someone a git is an insult?

dilap 6y ago

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?

Phlogistique 6y ago
Yes, it's standard in France at least.
- Phlogistique 6y ago
  Actually, both notations are described by an international standard, according to Wikipedia [1] [1]: https://en.wikipedia.org/wiki/Interval_(mathematics) https://en.wikipedia.org/wiki/Interval_(mathematics)
- dilap 6y ago
  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.
  - pmeunier 6y ago
    > 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.

keeganpoppen 6y ago

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! :)

waterofclear 6y ago

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!

pmeunier 6y ago
> 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.

jhoechtl 6y ago

> 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!

djhaskin987 6y ago

> 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".

Ezku 6y ago
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.
theonemind 6y ago
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”
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]