Hacker News Reader

Comment by dooglius | Hacker News Reader

The git behavior seems greatly preferable here. As mentioned in other threads, the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic, not any actual notion of correctness or semantics, so a human is needed to review the merge and re-test before anything can be known safe for pushing upstream. If anything, git is too lenient in allowing auto-merges to take place that could in principle change semantics, and it ought to enforce a manual review stage for any merge, regardless of whether the auto-merge heuristic succeeded or not.

View on HN

When the contents has a conflict, git and pijul behave similarly.

When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. Pijul will not.

As you say, neither will automatically check for correctness and you should run tests and CI when merging.

Pijul just removes the manual work when there is no conflict in the contents but the history is different.

> When the contents has a conflict, git and pijul behave similarly.

Not really: Pijul can record a conflict resolution as a patch, and apply it in a different context. Also, the conflict doesn't "come back", so you don't need extra hacks like rerere/jujutsu.

> Pijul just removes the manual work when there is no conflict in the contents but the history is different.

This is true, but could be confusing as our definition of conflicts isn't based on contents, but on operations, which is very different from Git (Git doesn't detect all conflicts).

> When the contents are identical, but the order of commits is different, git will conflict and require manual resolution.

But why would this normally happen? Different developers working on the same files which by chance make the same changes? Isn't that unlikely?

> the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic

This is completely false: in Pijul, any patches that could have been produced independently can be applied in any order without changing the result. There are 0 heuristics in Pijul, unlike in Git where even random line reshuffling can happen (there are examples in the "Why Pijul" section of the Pijul manual).

Obviously, deciding whether a merge has the correct semantic is Turing-complete, and Pijul doesn't try to do any of that.

Reply on news.ycombinator.com