<story><title>Pijul: Towards 1.0</title><url>https://pijul.org/posts/2020-11-07-towards-1.0/</url></story><parent_chain></parent_chain><comment><author>chriswarbo</author><text>I&amp;#x27;ve been keeping an eye on Pijul for a while, but assumed that (when it eventually stabilised) it personally wouldn&amp;#x27;t be worth the effort to switch from git.&lt;p&gt;I&amp;#x27;ve changed my mind now that they&amp;#x27;re tracking byte ranges instead of lines, with ranges decided in a customisable way at commit time. Semantic&amp;#x2F;format-aware versioning would be really nice. The easiest plugins to write would be s-expressions and JSON, and I could definitely see myself choosing Pijul for such repos in the future. If the patch-based approach is truly as nice as it appears, that might push me to use it more generally.&lt;p&gt;In fact, making an s-expression plugin which is robust across various Lisp dialects might be a good way to bootstrap the user community.&lt;p&gt;It would be nice to have for other languages too (C, Python, etc.), but they&amp;#x27;d (a) be more complicated and (b) more subject to churn.</text></comment>
<story><title>Pijul: Towards 1.0</title><url>https://pijul.org/posts/2020-11-07-towards-1.0/</url></story><parent_chain></parent_chain><comment><author>kevincox</author><text>I&amp;#x27;m really excited to see what Pijul ends up doing. I do love git, and I think its simple mental model of content addressed commits and trees is fantastic. However I do often find myself annoyed by the lack of a &amp;quot;change&amp;quot; concept other than the immutable commit. It seems that this results in review tools bending backwards to add that on top and it makes backports and other cherry-picks harder to follow.&lt;p&gt;One of the show-stopper complaints that I had about Pijul was the lack of a version identifier. However according to this post that has now been resolved which is fantastic news.</text></comment>