Hacker News Reader

> I don't understand what justifies Pijul's existence.

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.

So the justification is that some people want Darcs fundamentals but with the speed of git. Now: if you don't buy that Darcs does anything fundamentally better than git then obviously you also won't allow it as an argument for why Pijul is needed. But it is the argument.

The pijul manual starts with a "Why pijul" that describes why the more complex patch theory is an advantage.

https://pijul.org/manual/why_pijul.html

it outlines an example "bad merge" scenario where patches theoretic system gets it right and git does not.

https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html

Pijul is based on a different (and much more advanced) algorithm than Git. That doesn't mean it's the perfect tool - just as Git is better than SVN (even though they're based on the same underlying algorithms), Pijul might be the "SVN-like" tool waiting for its own Git...

Edit: having said that, Git isn't perfect either, I'm keeping my fingers crossed for an even better tool!

> just as Git is better than SVN (even though they're based on the same underlying algorithms)

Please explain this. Git is a content-addressable object-store. SVN is not. SVN’s architecture uses a diff as the basis for versioning which ties you to a particular diffing system, git uses snapshots and diffs can be generated using any algorithm because they aren’t part of the object-store; so what common “underlying algorithms” are you referring to?

AFAIK the basic merge algorithm for both Git and SVN is 3-way diff. Pijul instead uses commutative patches and a more complex merge algorithm.

Is it a better merge algorithm? Complexity on its own is not a selling point.

And if it is better, then I believe that it should also be possible to implement for Git, as the patch properties of Pijul and Darcs can easily be emulated.

Well if it's better at preventing bad merges, it's better, yes. Pijul might not be the best/optimal implementation of this algorithm, but it's still a step in the right direction (mainly because they optimized the algorithm significantly, reducing its complexity). Like, not all benefits of number theory (e.g. encryption) were discovered on the first day either.

1. It is associative, which make it predictable, and yes, better.

2. It is commutative, which makes it non-trivial to emulate with Git, a system where nothing commutes (on purpose).

Of course, you can obviously do your merges manually, rebase the world at each new commit, cherry-pick and rerere to emulate what Pijul gives you for free. But then is your job writing code or showing your proficiency at Git?

> Please explain this. Git is a content-addressable object-store. SVN is not.

They are both version control systems. People use them to track versions, as well as merging changes and diverging development branches. How data s stored is an implementation delail that doesn't reflect on the mental model.

Git is extremely different from SVN at all levels. Pijul does not appear particularly different from Git from a high-level perspective, however. Internal implementation details are very different, but they are largely invisible to the user.

It appears that Pijul is meant as an enhancement to Darcs (At least, the FAQ makes that out to be the case). Darcs which has its list of key features here: http://darcs.net/Features, all of which overlap entirely with Git.

Indeed, and it differs from Git in the same way as Darcs differs from Git: the basic block of history/code is not a commit, but a (commutative) patch.

Yes, which misses the point: Darcs does not mention any features that Git lacks, and lets its differences remain as largely invisible and irrelevant from the perspective of the user.

> Pijul might be the "SVN-like" tool waiting for its own Git...

Or Pijul is git, and Darcs is SVN in this case.

May I suggest maybe reading the manual before writing this kind of comment?

https://pijul.org/manual/why_pijul.html

> I don't understand what justifies Pijul's existence.

Someone wanted to create it, then created it, and probably had some fun while doing that.

First and foremost- its about a mental model. Pijuls model matches how one thinks of code changes. But in terms of actual implementation- pijul has better space management (a factor that solely dictates use of mercurial often).

Also- pijul has per path check out.

But again- all this is implementation- what works better is mental model.

Anybody who has cherry picked patch hunks or done a 3way merge knows what I'm talking about.

1. I see no difference. Git effectively works as differences. A commit can for all intends and purposes also be considered a "patch" (that just happens to also point to the parent it is meant to be applied to).

That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail.

2. So does git. git checkout treeish -- pathspec

Pijul does not solve a three-way merge. In fact, it does not seem to mention how merges are dealt with at all. Its model does nothing to even remotely affect the situation from what I can tell.

> That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail.

1. Sorry, I get that you might be angry at Pijul for some reason, but this is simply not true. The lack of associativity of 3-way merge is absolutely not hidden, and gets merges wrong sometimes.

But more fundamentally, the fact that commits must be ordered is not an implementation detail, it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository.

Conflicts in Pijul are detected correctly, and a conflicting state is another valid state, whereas in Git, a conflict is a failure to merge, and the user must solve the conflict before doing anything else. In particular, this implies that a conflict resolution in Git can be propagated to other repositories only if the two conflicting commits were merged at the exact same time in all repositories.

2. Working on parts of the repository in Git only works for checkout, you still have to clone the entire repository, and Git still has the entire repo, even it is not shown to the user in its entirety. This completely defeats the point of partial clones, and prevents, in many cases, the use of Git on monorepos. That said, I'm not sure why this is the case, Git could very well produce a commit using a tree whose blobs are not all downloaded, just like when you commit from a shallow clone.

But even if this worked, Git requires you to send the entire history of the full repository if you want to clone it to a remote machine, whereas Pijul lets you select the patches relative to just a part of the repository. This is because in Pijul, patches commute! If you place your patches in a sequence, you can reorder the patches you want to send (without changing their identifier) to be the first ones in the sequence, and then send just a prefix of the sequence. All this without any extra operation, rebase or anything else.

What I dislike about Pijul is that it entirely fails to sell itself.

Pijul is a product that seeks adoption. I'm a customer. Pitch.

Pijul fails to present me any reason or example for its superiority to the status quo, Git. It only provides vague points like simply claiming to be more "correct". I need to know how my workflow will improve as a result of replacing Git with Pijul.

Sure, you might say that I'm not the target, but as a software developer running my own DevOps product and consultancy company, I don't find that to be the case.

For your specific counter-arguments:

1. Pointing out a corner-case pain point with Git, and simply stating that Pijul will be "correct" is not at all informative. Git has countless pain points, and so will Pijul have. What matters is the 90% experience, not the corner cases.

"A conflicting state is another valid state" does not mean anything to a user. The source is not in a valid state during conflict, and sharing invalid source is not interesting, so this falls under implementation details again.

Merges have pros and cons, which is why Git also has other mechanisms which the users can select, such as rebase.

Again, what one needs to know is how the workflow of a developer is affected, not how beautiful the internal structures may end up being.

2. Ah, a partial checkout and a partial clone differ, at least in Git terminology, which is the status quo at the current time.

However, what people care about is not the ability to perform a partial clone, but the speed of certain operations. If a full clone is fast, the user won't give a damn about partial clones.

Instead, what one should then put as a prominent feature is monorepo capability, and direct performance comparisons between Git and Pijul.

However, do note that Microsoft appears to handle monorepos in Git just fine with GVFS, through partial clones.

Also, the ability to reorder patches without changing their identifier will to many be an anti-feature which might render Pijul a no-go. From a user-perspective, Pijul and Git are both equally capable of reordering patches, Pijul just lacks the ability to easily and uniquely identify an entire tree state.

You seem to be faster at writing than at reading, I already answered your point 1:

> it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository.

Any team with enough people, or working at a fast enough pace, knows this doesn't work in Git. Pijul completely solves it by thinking in an entirely different way (changes instead of snapshots). This is not an implementation detail at all, the two mental models are extremely different.

About your point 2, what can I say? You picked the example, and now that you're not liking it anymore, you are trying to blame it on me? I don't find that fair.

Sorry, but as another commenter said, you may not like Pijul for whatever reason or think it's "bad" someone is working on it, but your argument that git's model is not exposed to the user and that there is no difference is simply not true. I recently had issues with Git's model of merging come up and it broke a very important build in our Linux distribution (OpenJDK), due to an erroneous merge that Git applied without warning or conflict: https://github.com/NixOS/nixpkgs/commit/5d0ef3fd900769e82175...

To repeat the issue: I basically broke a build on our Linux distribution when I cherry picked a change after what git thought was a file rename -- it was not actually a file rename. An entire new file that was mostly similar was added, effectively resulting in Git thinking it was a move.

    - `10.nix` for JDK 10 was removed, and JDK 11 (via `11.nix`) was added in 1bd7b98c7975136ddd6183a155e90688fd5b3e43, all in the same commit
     - JDK 11 was only added in `master`, not in `release-18.09`
     - Because these files were substantially the same, `git` tracked this 10 -> 11 upgrade (from `10.nix` to `11.nix`) heuristically as a file rename.
     - I committed 162914742327002d49bd1dde424d399842ff7b5f on `master` as a change to OpenJDK 11
     - I cherry-picked that to `release-18.09`, in this commit
     - Git saw that the change was applied to `11.nix`, but that change was not applied on this branch, so that file did not exist.
     - But git *thinks* that `11.nix` came directly from `10.nix`, through a file rename, i.e. the files are "the same" in some sense (even though they substantially differ in functionality, now)
     - Therefore, `git` concludes it's safe and appropriate to "rebase" this cherry-pick on top of `10.nix`
     - And then the build fails, because ZGC is not available in OpenJDK 10

-----

I used Darcs for years before moving to Git, and this would have never happened with either Darcs or Pijul -- and not just because they actually track renames more accurately, more complicated merge issues that can arise from Git's model are also handled elegantly and correctly. The tool would have instead warned me that any cherry pick would have required a dependent patch (the one that added OpenJDK 11) that wasn't already there, and I would have been immediately informed of it -- a case that Git completely failed at. That's the wrong behavior, no matter what way you cut it. (Of course, I use Git every day despite this, and it works about 90% of the time.)

Many other very useful workflows are made easier by the fact that in the model of Darcs and Pijul, patches are treated as commutative, and that fact is tracked correctly -- doing things like cherry-picks to stable branches (something I did for years as part of a large project -- one that use Darcs first and moved to Git!) becomes far easier because it's always clear when dependent changes are needed and how they interact, and when you want to pull them vs author bespoke patches for different branches, etc.