<story><title>Pijul for Git users</title><url>https://nest.pijul.com/tae/pijul-for-git-users</url></story><parent_chain><item><author>arghwhat</author><text>I don&amp;#x27;t understand what justifies Pijul&amp;#x27;s existence. While I agree that Git is a complicated monster that takes ages to learn how to use for most people, Pijul does not seem to solve any problems with Git. Instead, it has many problems that Git solves. From a user-perspective, it doesn&amp;#x27;t even seem like there&amp;#x27;s much of a difference, despite the (annoying) choice of alternate command verbs (i.e. &amp;quot;record&amp;quot; rather than &amp;quot;add&amp;#x2F;commit&amp;quot;).&lt;p&gt;It doesn&amp;#x27;t really seem like the authors fully understand Git, and what problems it solves.&lt;p&gt;&amp;gt; [...] in Git each commit is related to a parent [...] But in Pijul there&amp;#x27;s no timeline and branches are just sets of patches.&lt;p&gt;To me, that makes Pijul much, &lt;i&gt;much&lt;/i&gt; less capable as a version control system. In Git, knowing the commit ID means that you know the &lt;i&gt;full source tree state&lt;/i&gt; with the certainty being equal to the risk of a commit ID hash collision.&lt;p&gt;With just individual, unrelated patches applied in sequence, you have no such guarantee, and no knowledge of the current state of the repository.&lt;p&gt;Of course, you could add a seperate state tracking system allowing ID&amp;#x27;s to point to an immutable and unique set of patches in a certain sequence, but doing so just means that you have now implemented features identical to Git, with just a different internal representation (i.e. irrelevant differences for the user).&lt;p&gt;&amp;gt; [...] And push those changes in whatever order we want&lt;p&gt;You can do the same in Git (see interactive rebase, cherry-picking, similar). It rewrites the commit IDs in order to maintain the previously mentioned property of representing the state of the repository, but that&amp;#x27;s an implementation detail.</text></item></parent_chain><comment><author>alkonaut</author><text>&amp;gt; I don&amp;#x27;t understand what justifies Pijul&amp;#x27;s existence.&lt;p&gt;The argument basically is: Darcs is better at the fundamentals than git is, and the reason for its lack of popularity is that it implemented those fundamentals inefficiently leading to exponential time use in some cases.&lt;p&gt;So the justification is that some people want Darcs fundamentals but with the speed of git. Now: &lt;i&gt;if you don&amp;#x27;t buy that Darcs does anything fundamentally better than git&lt;/i&gt; then obviously you also won&amp;#x27;t allow it as an argument for why Pijul is needed. But it &lt;i&gt;is&lt;/i&gt; the argument.&lt;p&gt;The pijul manual starts with a &amp;quot;Why pijul&amp;quot; that describes why the more complex patch theory is an advantage.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;pijul.org&amp;#x2F;manual&amp;#x2F;why_pijul.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;pijul.org&amp;#x2F;manual&amp;#x2F;why_pijul.html&lt;/a&gt;&lt;p&gt;it outlines an example &amp;quot;bad merge&amp;quot; scenario where patches theoretic system gets it right and git does not.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;tahoe-lafs.org&amp;#x2F;%7Ezooko&amp;#x2F;badmerge&amp;#x2F;simple.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;tahoe-lafs.org&amp;#x2F;%7Ezooko&amp;#x2F;badmerge&amp;#x2F;simple.html&lt;/a&gt;</text></comment>
<story><title>Pijul for Git users</title><url>https://nest.pijul.com/tae/pijul-for-git-users</url></story><parent_chain><item><author>arghwhat</author><text>I don&amp;#x27;t understand what justifies Pijul&amp;#x27;s existence. While I agree that Git is a complicated monster that takes ages to learn how to use for most people, Pijul does not seem to solve any problems with Git. Instead, it has many problems that Git solves. From a user-perspective, it doesn&amp;#x27;t even seem like there&amp;#x27;s much of a difference, despite the (annoying) choice of alternate command verbs (i.e. &amp;quot;record&amp;quot; rather than &amp;quot;add&amp;#x2F;commit&amp;quot;).&lt;p&gt;It doesn&amp;#x27;t really seem like the authors fully understand Git, and what problems it solves.&lt;p&gt;&amp;gt; [...] in Git each commit is related to a parent [...] But in Pijul there&amp;#x27;s no timeline and branches are just sets of patches.&lt;p&gt;To me, that makes Pijul much, &lt;i&gt;much&lt;/i&gt; less capable as a version control system. In Git, knowing the commit ID means that you know the &lt;i&gt;full source tree state&lt;/i&gt; with the certainty being equal to the risk of a commit ID hash collision.&lt;p&gt;With just individual, unrelated patches applied in sequence, you have no such guarantee, and no knowledge of the current state of the repository.&lt;p&gt;Of course, you could add a seperate state tracking system allowing ID&amp;#x27;s to point to an immutable and unique set of patches in a certain sequence, but doing so just means that you have now implemented features identical to Git, with just a different internal representation (i.e. irrelevant differences for the user).&lt;p&gt;&amp;gt; [...] And push those changes in whatever order we want&lt;p&gt;You can do the same in Git (see interactive rebase, cherry-picking, similar). It rewrites the commit IDs in order to maintain the previously mentioned property of representing the state of the repository, but that&amp;#x27;s an implementation detail.</text></item></parent_chain><comment><author>tomp</author><text>Pijul is based on a different (and much more advanced) algorithm than Git. That doesn&amp;#x27;t mean it&amp;#x27;s the perfect tool - just as Git is better than SVN (even though they&amp;#x27;re based on the same underlying algorithms), Pijul might be the &amp;quot;SVN-like&amp;quot; tool waiting for its own Git...&lt;p&gt;Edit: having said that, Git isn&amp;#x27;t perfect either, I&amp;#x27;m keeping my fingers crossed for an even better tool!</text></comment>