Live data from Hacker News

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

nest.pijul.com

91–100 of 125 posts

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

#91
post #23

FWIW, this has gotten a certain amount of attention on HN over the years since it was begun but it's instantly noticeable that patches tailed off and stopped last June. Naturally that raises the question of "is this even still alive", and last month the starter of the project, Pierre Meunier, posted a response to a query about that indicating a major rewrite is in progress: ---- https://discourse.pijul.org/t/is-this-…

The combination of > (2) thinking about the future and sustainability of the project, including its funding. and the rewrite apparently not happening in the open casts some doubt as to whether the project will remain fully open source.

> […] the rewrite apparently not happening in the open […]

That's a major red flag for a FOSS DVCS that aims to exist as a valid alternative for existing tools like git. Fine for a hobby project, portfolio project, or experiment of course.

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

#92
post #77

Earlier quoted context omitted.

> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. At best, the argument made by Pijul's backers is that Pijul implements this feature differently and in a way that arguably may be creating a problem where in Git there is none.

Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.

I guess it's a matter of personal opinion but as a git and svn user I simply fail to see any relevance or value in Pijul's selling point regarding cherry picking. It feels that the argument for Pijul starts from a problem that never existed, and even so the selling points fail to present a case for the alternative.

And to be honest, if the worse pain point of git that the Pijul team addressed was git's cherry-picking, it looks like they failed to do any form of cursory homework on Git.

But hey, just my 0.02€. Everyone should use the tools that they prefer, and if someone has a problem with Git cherry-pick that they feel is better solved by switching tooling instead of reviewing the problems then have fun.

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

#93
post #75

Earlier quoted context omitted.

On cherry-pick dependencies: there is no way that any VCS can solve that problem for you, because dependencies can be (and often are, for the projects I've worked on) non-local. That is, you can have a dependency even though the changes appear to be unrelated from a textual point of view. I'm all for developing better tooling for digging into blame-history, which is more generally useful and would cover the textual d…

> but you shouldn't believe that that solves the dependency problem. I don't think anyone believes that. The dependencies in Pijul are the minimal dependencies that make the patch application possible, they are by no means semantic (you can totally add dependencies manually, btw). However, for the particular use case explained above (stable branches, backporting bugs), the default behaviour of Pijul already gives you…

Right. I guess what I'm trying to say is that this isn't anything truly fundamental about Pijul. You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git.

The fact that this particular feature already exist in Pijul is not a great argument for changing the underlying data structure, which is what switching to another DVCS is.

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

#94
post #23

FWIW, this has gotten a certain amount of attention on HN over the years since it was begun but it's instantly noticeable that patches tailed off and stopped last June. Naturally that raises the question of "is this even still alive", and last month the starter of the project, Pierre Meunier, posted a response to a query about that indicating a major rewrite is in progress: ---- https://discourse.pijul.org/t/is-this-…

The combination of > (2) thinking about the future and sustainability of the project, including its funding. and the rewrite apparently not happening in the open casts some doubt as to whether the project will remain fully open source.

> the rewrite apparently not happening in the open

I'm the author of the rewrite. It will almost certainly be open source when it's done, but it is not open right now, because:

- the license of the current version has not been properly observed by other projects in the past.

- this project keeps getting bashed for "corrupting repositories" and "changing formats constantly", even though it is announced as experimental everywhere (also, some corruption claims have been wrong in the past, and we have released converters every time the formats have changed).

Therefore, allowing people to test the new version as it is being debugged would probably not improve this situation.

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

#95
post #77

Earlier quoted context omitted.

Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.

I guess it's a matter of personal opinion but as a git and svn user I simply fail to see any relevance or value in Pijul's selling point regarding cherry picking. It feels that the argument for Pijul starts from a problem that never existed, and even so the selling points fail to present a case for the alternative. And to be honest, if the worse pain point of git that the Pijul team addressed was git's cherry-picking…

I think you've failed to read the other answers I and others have provided.

But hey, everyone should read the answers they want, if someone wants to pick only the ones that are the easiest to dismiss then have fun.

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

#96

Earlier quoted context omitted.

I guess it's a matter of personal opinion but as a git and svn user I simply fail to see any relevance or value in Pijul's selling point regarding cherry picking. It feels that the argument for Pijul starts from a problem that never existed, and even so the selling points fail to present a case for the alternative. And to be honest, if the worse pain point of git that the Pijul team addressed was git's cherry-picking…

I think you've failed to read the other answers I and others have provided. But hey, everyone should read the answers they want, if someone wants to pick only the ones that are the easiest to dismiss then have fun.

> I think you've failed to read the other answers I and others have provided.

I read them and it was based on those comments, and also the half a dozen previous discussions on Pijul here at HN, that I formed my opinion.

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

#97
post #93

Earlier quoted context omitted.

> but you shouldn't believe that that solves the dependency problem. I don't think anyone believes that. The dependencies in Pijul are the minimal dependencies that make the patch application possible, they are by no means semantic (you can totally add dependencies manually, btw). However, for the particular use case explained above (stable branches, backporting bugs), the default behaviour of Pijul already gives you…

Right. I guess what I'm trying to say is that this isn't anything truly fundamental about Pijul. You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git. The fact that this particular feature already exist in Pijul is not a great argument for changing the underlying data structure, which is what switching to another DVCS is.

> You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git.

Absolutely, the only difference is the time you'll waste managing your branches (creating, rebasing and merging them).

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

#98

Earlier quoted context omitted.

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

This is a network error, not a corruption error. I agree the CLI is not yet stable.

I guess it was caused by a network error, but it still ended up with the repository in a corrupt state (with the patches "existing" but invisible).

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

#99

Earlier quoted context omitted.

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

You're basically saying the Nest is still primitive. Yes it is! It's even blinking on its front page https://nest.pijul.com

And that's fine! I just wish I didn't have to use it (before it is actually considered ready, at least).

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

#100

Earlier quoted context omitted.

You're basically saying the Nest is still primitive. Yes it is! It's even blinking on its front page https://nest.pijul.com

And that's fine! I just wish I didn't have to use it (before it is actually considered ready, at least).

You don't have to use the Nest at all, Pijul can work on your own server via SSH, the protocol just runs commands through SSH.
Post reply on HN