Live data from Hacker News

Pijul: a distributed version control system, written in Rust (2019)

nest.pijul.com

61–70 of 125 posts

Re: Pijul: a distributed version control system, written in Rust (2019)

#61

Earlier quoted context omitted.

What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?

It is not at all about not being Git. The absolute best reason is that Pijul actually has the properties that people think Git has: - in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around. - in Pijul, patches commute. Most Git users try to simulat…

> patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B

that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final state change?

Re: Pijul: a distributed version control system, written in Rust (2019)

#62

Earlier quoted context omitted.

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.

Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh ( https://cargo.io/crates/thrussh ), which aim at making the UX as smooth as possible.

Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement.

Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix.

I am interested in https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.

Re: Pijul: a distributed version control system, written in Rust (2019)

#63
I use and like git, but I feel like I'm working against it sometimes. I much prefer a rebase workflow with a linear history, and a chance to reorganize and reword commits so they make more sense. Git allows this workflow, and does quite a good job of it, but I feel nudged towards "just merge it".

If a VCS could do anything to improve the rebase workflow, that would be pretty interesting to me.

Re: Pijul: a distributed version control system, written in Rust (2019)

#65

Latest commit from 7 months ago. Also, anecdotally I've heard it's not very user friendly in practice; more like a research prototype than usable software.

If anything, a user friendly git is what we need, not yet another tool with bad UX.

Fossil?

Re: Pijul: a distributed version control system, written in Rust (2019)

#66
post #36

Last I tried it (a couple years ago), repositories got corrupted. I'd like something to replace darcs, but so far I haven't found it.

Well, for a project explicitly announced as experimental (there's even a blinking paragraph on nest.pijul.com), two years is quite a while. The repository of Pijul itself got corrupted several times, but the last time was certainly more than a year ago.

Last I tried it (in November), repositories got corrupted.[0]

I wish Carnix would just use Git instead, but I get why that's not happening.

[0]: https://nest.pijul.com/pmeunier/carnix/discussions/39

Re: Pijul: a distributed version control system, written in Rust (2019)

#67
post #36

Last I tried it (a couple years ago), repositories got corrupted. I'd like something to replace darcs, but so far I haven't found it.

Well, for a project explicitly announced as experimental (there's even a blinking paragraph on nest.pijul.com), two years is quite a while. The repository of Pijul itself got corrupted several times, but the last time was certainly more than a year ago.

While that's a reasonable position in some ways I certainly don't get the impression that I should assume Pijul is not up to the most fundamental guarantee of an SCM: not losing my code. A page telling me why I should use Pijul probably should explain that I shouldn't use it for anything that matters in the most trivial of ways and yours doesn't.

https://pijul.org/manual/why_pijul.html

Re: Pijul: a distributed version control system, written in Rust (2019)

#69

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 woul…

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 si…

> 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

[1]: https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hs...

Re: Pijul: a distributed version control system, written in Rust (2019)

#70
post #61

Earlier quoted context omitted.

It is not at all about not being Git. The absolute best reason is that Pijul actually has the properties that people think Git has: - in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around. - in Pijul, patches commute. Most Git users try to simulat…

> patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final stat…

Associativity is not about changing the order but about a different grouping:

    ( A B ) C = A ( B C )
Post reply on HN