Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

The lack of a clear “why this rewrite was needed” somewhere accessible is a pretty big “f u” to anyone that evangelized for Pijul in the past.

View on HN

My uderstanding is that they wanted to change the algorithm and that the codebase needed a major refactoring. I think there was performance issues with the first implementation and design so they had to make very large change.

https://discourse.pijul.org/t/is-this-project-still-active-y...

More on that very soon on the website. The reason is performance and scalability.

Pijul was always advertised as experimental, and Anu is the result of that experiment.

> Pijul was always advertised as experimental, and Anu is the result of that experiment.

So it should actually be "safe" to buy in to now? If I put my project into Anu, I shouldn't get stranded in 5 years?

Experimental doesn’t mean leaving everyone in the dark to go develop a complete replacement in secret with nary an update or heads-up.

On the other hand, libpijul received 0 external contributions over the three years during which it was public.

The biggest contribution I got was from someone who rediscovered it independently after asking me about it, and didn't even care to respect the license.

Moreover, the formats of an experimental tool, especially when it is based on new math, need to change frequently. Every single time we've done it in the past, we heard weird comments here, on Reddit and Twitter that our theory would never work because the implementation was not there yet.

There were also unfortunate professional choices I don't want to comment on, which forbade me to work on Pijul other than sometimes on the weekends. I ended up resigning in July 2020, and have worked on the new Pijul more or less 100% since then.

Best of luck, from a fellow open source developer and maintainer.

> why this rewrite was needed

We all know why

No we don't. Care to enlighten us?

The new codebase is apparently in Rust. Perhaps the parent is being sarcastic with respect to the quantity of results here: https://hn.algolia.com/?q=rewrite+in+Rust

The old codebase was also in Rust. So I don't think this applies here.

My guess would be Rust. That is assuming the original reason was not not in fact making a "better Git".

The old code base was also in Rust.

I said "assuming". In no way I was pretending to be correct. Just a wild guess.

Totally! Just letting you know that’s not it.

Why though?

Soaking as someone who is completely unfamiliar with Pijul, the explanation on this page is pretty lackluster.

"It is based on changes rather than snapshots"

Well, every VCS I'm familiar with is based on changes/deltas. I assume that these terms have specific meanings here that I'm not familiar with, but it manages to sound like the author has never heard of git or Mercurial.

Git actually does not work with deltas; each commit contains the hash of a tree object [0], which contains the hashes of the files within it [1]. This tree is effectively a snapshot, since it contains every file hash in the working directory at a certain point in time. Since Git uses the file hash instead of just the file path, it doesn't have to download the files whose hashes haven't changed since the last commit, which is what makes it behave somewhat as if it is operating on a delta.

[0] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_gi... [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_tr...

git fundamentally tracks and stores snapshots, not changes. I believe mentioning this is meant to emphasize a difference between Anu (or Pijul) and git.

This is correct. The common misunderstanding is due to the fact that gits pack files are delta compressed, but that's a implementation detail.

Reply on news.ycombinator.com