5 ms·

The implications of Pijul are really interesting. Some of the guarantees afforded by Pijul's model are clearly superior to those afforded by Git, but I can't he

The implications of Pijul are really interesting. Some of the guarantees afforded by Pijul's model are clearly superior to those afforded by Git, but I can't help but get the impression that Pijul is: 1. considerably more complex under the sheets, and 2. considerably more complex in situations you're going to have to deal with as a user. It would be nice to read an article from someone familiar with Pijul, that would take a look at the "ugly" (from the user's perspective) parts, and either explain how they aren't issues in practice, or at least show how you would handle them and argue why the benefits outweigh the costs. For example, accurately representing repository states with files appears difficult: the page on Pijul's theory[0] explains how Pijul does not limit the repository to containing valid states, and mentions that "...else, we say the file has a conflict, and presenting the state of the file to the user in an intelligible way is not obvious.". There's an independent article about Pijul[1] that gives some examples of how you could end up with two different conflict states in Pijul that render into identical files. I also had a look in the patch list for the master branch[2]. I managed to find a few patches I couldn't understand by looking at them. I realize that Pijul is still some ways from being ready for mass consumption, but the selling point of Pijul is its theory of patches. The documentation for "pijul patch"[3] notes that outputting patches as text "may lose information", and that "the text representation is merely a pretty-printed representation, and is not sufficient to apply the patch". This suggests to me that the difficulty in viewing those patches is at least partially due to viewing Pijul patches being a hard problem. Here's an example, "Fixing a conflict with #387": https://nest.pijul.com/pijul_org/pijul:master/patches/6E7KeeqoxngvDnPvBbQDSeMvWZLN2qUMUvDnF8wADb42iZtLFWHbQSf7YAyx5D37ZuoRY3W2B5opjUJt5ZPHGUpY https://nest.pijul.com/pijul_org/pijul:master/patches/6E7Kee... Some lines at the top appear to be for informative purposes. They reappear later on, but slightly different (e.g. imports reordered, or with changed whitespace), and without any color (green or red) that would indicate that they were added or removed. They're shown in a context (e.g. line 219, 222) where they fit in as additions together with other lines that were added, though. The output of "pijul patch" for this patch[4] looks somewhat similar, and likewise not very easy to digest. I really want to like Pijul, but I'm worried that it's too powerful and requires too much from the user. I would like to be wrong, though, so I would really welcome an article explaining these "darker" sides. 0: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html 1: https://jneem.github.io/pijul/ https://jneem.github.io/pijul/ 2: https://nest.pijul.com/pijul_org/pijul:master/patches https://nest.pijul.com/pijul_org/pijul:master/patches 3: https://pijul.org/manual/reference/patch.html https://pijul.org/manual/reference/patch.html 4: https://pastebin.com/b8XT5WPE https://pastebin.com/b8XT5WPE

pmeunier 7y ago
Hi! I'm one of the authors. > 1. considerably more complex under the sheets, and Yes it is, which sometimes comforts me when I think of how long it's taken to get a version that works reasonable well. That said, it's also not the kind of complexity that goes against performance, but rather the kind that makes it hard to process Pijul repositories or patches with independent tools. > 2. considerably more complex in situations you're going to have to deal with as a user. I've used it quite a bit, but the biggest repository I've every interacted with is Pijul itself, which is a rather small codebase, so I don't know how the UX scales. I find it as easy to use as Darcs, with the caveat that patches are not always as intelligible as in Darcs. That said, patches solving conflicts are weird and/or wrong in Darcs, and they are quite simple in Pijul. And I believe conflicts are the situations where you need the most simplicity and clarity. > It would be nice to read an article from someone familiar with Pijul, [..] That is a really nice suggestion for a blog post, it's now on my todo list. Thanks! > For example, accurately representing repository states with files appears difficult This is unfortunately a difficulty intrinsic to the problem. Git has the same issue, it just doesn't really show it because the conflicts that cause this are shown in a very basic way (there's only so much that diff3 can guess). > I managed to find a few patches I couldn't understand by looking at them. There are two issues: one is that the Nest doesn't yet have the best algorithms to render patches (but is likely to improve a lot with the new version of libpijul I'm writing), and the other one is that some patches might have been converted from a previous patch format, which makes them weird. > I really want to like Pijul, but I'm worried that it's too powerful and requires too much from the user. The goal is quite the opposite! For starters you can use it just like Git (with branches, and only with better merges). But then when you realise you don't need branches, everything becomes much simpler, and the tool stops getting in your way. For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was using Pijul about 100% of the time I contribute or even use my local clone.
- Nullabillity 7y ago
  > For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was using Pijul about 100% of the time I contribute or even use my local clone. That's a reasonable reaction for someone who is very familiar with Pijul, but as a newcomer my reaction is precisely the opposite. When trying to figure out some issue I have with some software, I quickly run into two questions: 1. How did the source code look for the release X that I have installed? 2. Did patch Y make it into release X? Git makes it trivial to answer both of those questions. Both GitHub and GitLab show all versions as tags (by convention) that are reachable in 1-2 clicks from the project home page, and a given commit page shows all tags that include it. With Pijul/Nest I have no idea where to even start. I see no tag list anywhere[0], and patch pages look like gibberish[1]. [0]: https://nest.pijul.com/pmeunier/carnix:master/patches https://nest.pijul.com/pmeunier/carnix:master/patches [1]: https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hsejXs2L1iKJysZ2Anz4MLReLkm4C4mxbkxHNPmitSWSn8uEkzuDEL7yosY3yCiKMSx3D8ofokM9rTL1ZKam https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hs...

pmeunier 7y ago

Hi! I'm one of the authors. > 1. considerably more complex under the sheets, and Yes it is, which sometimes comforts me when I think of how long it's taken to get a version that works reasonable well. That said, it's also not the kind of complexity that goes against performance, but rather the kind that makes it hard to process Pijul repositories or patches with independent tools. > 2. considerably more complex in situations you're going to have to deal with as a user. I've used it quite a bit, but the biggest repository I've every interacted with is Pijul itself, which is a rather small codebase, so I don't know how the UX scales. I find it as easy to use as Darcs, with the caveat that patches are not always as intelligible as in Darcs. That said, patches solving conflicts are weird and/or wrong in Darcs, and they are quite simple in Pijul. And I believe conflicts are the situations where you need the most simplicity and clarity. > It would be nice to read an article from someone familiar with Pijul, [..] That is a really nice suggestion for a blog post, it's now on my todo list. Thanks! > For example, accurately representing repository states with files appears difficult This is unfortunately a difficulty intrinsic to the problem. Git has the same issue, it just doesn't really show it because the conflicts that cause this are shown in a very basic way (there's only so much that diff3 can guess). > I managed to find a few patches I couldn't understand by looking at them. There are two issues: one is that the Nest doesn't yet have the best algorithms to render patches (but is likely to improve a lot with the new version of libpijul I'm writing), and the other one is that some patches might have been converted from a previous patch format, which makes them weird. > I really want to like Pijul, but I'm worried that it's too powerful and requires too much from the user. The goal is quite the opposite! For starters you can use it just like Git (with branches, and only with better merges). But then when you realise you don't need branches, everything becomes much simpler, and the tool stops getting in your way. For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was using Pijul about 100% of the time I contribute or even use my local clone.

Nullabillity 7y ago
> For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was using Pijul about 100% of the time I contribute or even use my local clone. That's a reasonable reaction for someone who is very familiar with Pijul, but as a newcomer my reaction is precisely the opposite. When trying to figure out some issue I have with some software, I quickly run into two questions: 1. How did the source code look for the release X that I have installed? 2. Did patch Y make it into release X? Git makes it trivial to answer both of those questions. Both GitHub and GitLab show all versions as tags (by convention) that are reachable in 1-2 clicks from the project home page, and a given commit page shows all tags that include it. With Pijul/Nest I have no idea where to even start. I see no tag list anywhere[0], and patch pages look like gibberish[1]. [0]: https://nest.pijul.com/pmeunier/carnix:master/patches https://nest.pijul.com/pmeunier/carnix:master/patches [1]: https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hsejXs2L1iKJysZ2Anz4MLReLkm4C4mxbkxHNPmitSWSn8uEkzuDEL7yosY3yCiKMSx3D8ofokM9rTL1ZKam https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hs...