| I looked into Pijul in the past but in the end the model seemed worse than git to me. Git is a snapshot based model and so doesn't leak any implementation details about patches themselves. Every user can use whatever diffing algorithm they want when generating patches for use in three way merge and then only the results are stored. In fact with git you don't even need to use three way merge, the only thing that matters is that you say "I merged A and B and this is what the tree looks like as a result". Pijul being based on patches encodes patch information into the repo. Each line belongs to a patch and it can depend on the diffing algorithm which patch owns a particular line. This is a big drawback and so we should hope to get some serious benefits to make up for it, but I don't think we do. One of Pijul's main selling points is the ease of cherry-picking. They make the claim that cherry picking "just works" but I think this misses the big picture. Pijul's cherry picking only "just works" with respect to merging lines of code. It can automatically pull in patches that the lines of code you are merging depend on for the merging algorithm, but it can not track things like "This calls a function introduced in patch X" which makes the cherry-picking functionality of very little value. The biggest problem IMO is that Pijul is more similar to git rebase than git merge. What I mean is that it forces you to resolve conflicts that you probably wont ever care about. Let's say I have a local git branch with 10 commits on top of master. Now if I update my master and do "git rebase master" I must make sure that each one of those 10 commits resolves cleanly on top of the new master. It's common to get into situations where you would have to resolve conflicts in several of those rebase steps but a merge which did a three way merge of the tops of both branches would result in few or no conflicts. Pijul is like rebase in that it forces you to consider the full history of all the patches in a set which requires to resolve arbitrary conflicts. The benefit of resolving those conflicts is that it can help with cherry-picking, but I don't want to be doing this work all the time for an incomplete solution to a rare operation. I even made some test repos in both Git and Pijul to verify that Pijul forces you to resolve conflicts that three-way merge doesn't care about. It's certainly possibly I got some information wrong about Pijul. Please correct me if I have! |
That's actually the case, because you can totally simulate Git using Pijul if you want, except for the weird merges where Git shuffles up lines randomly.
> This is a big drawback and so we should hope to get some serious benefits to make up for it.
It is not a drawback at all, there are no downsides to it, and we get the very serious benefit that merges are associative, which is not the case in Git. Indeed, in Git (using diff3 to merge), when Alice adds lines at the beginning of a file and Bob adds lines at the end, some of Bob's line can get merged into Alice's new lines.
> it can not track things like "This calls a function introduced in patch X" which makes the cherry-picking functionality of very little value.
You can totally do that in Pijul by adding extra dependencies, and moreover, this is like saying `git rebase` adds very little value to Git.
> Pijul is like rebase in that it forces you to consider the full history of all the patches in a set which requires to resolve arbitrary conflicts
It is actually the exact opposite: Git forces you to reconsider those conflicts (there's even `git rerere`), whereas Pijul only shows you the unresolved conflicts. Once a conflict is solved in Pijul, it's solved by a patch, and solved forever.