HN Explorer

Ask HN: How Stable Is Pijul?

22 points by poletopole ↗ HN
I read Pijul’s blog the other day and it looks like it’s close to 1.0 as of November. Is Pijul still experimental, meaning, are the theories behind it still a WIP or is it just that it isn’t as performant as the creator or community would wish?

4 comments

[ 0.20 ms ] story [ 17.2 ms ] thread
pmeunier
I'm the lead developer of Pijul. The theory is 99% there. Things are still moving a little bit, but it's mostly cleanup at this stage, the maths are solid. The UI is also moving, as users discover "weirdnesses" (which most of the time are places where Pijul's defaults differ from Git's).

There are two things I'm working on at the moment, and when these are done I believe 1.0 will be super close:

- Future-proofing the formats. There is one major thing I'd like to address before calling it 1.0, and that's code refactoring. It isn't supported at the moment, and Pijul is perfectly usable without that, but I'd like to keep the possibility of implementing it in the future open. I believe the current formats allow that, but I still need to be 100% certain.

- Merging two giant histories takes a time linear in the size of the history on the remote repository. Of course this isn't an operation you want to do very often, but it may become problematic for truly gigantic repositories, and I know how to fix that. This is planned to be a separate project at the moment, but it does require some support from the libpijul API.

pmeunier
By the way, when I wrote "code refactoring", I didn't mean "refactor Pijul", but rather supporting the following scenario:

- Alice splits a file into multiple smaller files. - In parallel, Bob changes one function.

At the moment, when they merge, they will get a conflict (both the same conflict, obviously), but I think it could be possible to remove the conflict.

poletopole
Thank you for taking the time to answer my questions. I should have asked also if Pijul’s current API or user facing semantics will change with 1.0?

I admire how challenging developing Pijul must be, especially when some of us here critique it without bothering to understand it, so my hat is off to you! But I think most of us here are eager to use Pijul, myself including.

pmeunier
Thanks! It is a little bit challenging indeed. I've worked on worse systems before, and as always with asynchronicity, the devil is in the details, and there are more details than anyone who hasn't written it can imagine ;-)

I don't expect the semantics to change much. The things that need polishing are probably on documentation, error messages, and network. The latest bugs in Pijul itself (i.e. not Libpijul) included handling the case where your HTTP connection drops while you're downloading, and keeping your connection busy, that sort of stuff.