[dahart]

Thanks for the reply and explanation. You’re convincing me to at least try it.

I want to understand first-hand by using Pijul what you mean by not needing rerere and having no such thing as a bad merge. Do you mean it’s not possible to make merge mistakes, or just that the default choices made by the version control system are never wrong? The only times I’ve ever needed rerere are when I made mistakes rebasing or resolving merge conflict, and I had to roll back and do a bunch of them again. In that case, I chose to manually undo my merge, so rerere is just saving time from having to repeat all of my decisions when only a few were wrong.

I like the idea of Pijul being better at blame. Of course the main thing that needs to happen is tooling. Git’s blame has been fine but the UI for it stinks. This is maybe the feature I miss from Perforce the most; the blame UI in P4V is superlative compared to git.

[pmeunier]

It's indeed not possible to make merge mistakes in Pijul, in the sense that the order between lines is always preserved: if line A comes before B in one repository, A will be before B in all repositories that have these two lines.

Moreover, merge is associative, which is the intuitive idea of a "good merge", in the sense that merging your patches one by one is the same as merging them all at once (this is false in Git).

In Pijul you can't "make mistakes rebasing". A repository is a set of patches (set as in maths), you can add patches or remove patches from the set, and that's about it. Two repositories with the same set of patches (possibly applied in different orders) are totally equivalent (in particular they have the same file contents).

So, rebasing in this case would be just the operation of adding some patches and removing others, and hence you can't make mistakes doing that, because there is no manual merge operation needed (of course you still need to solve your conflicts).