Hacker News Reader

Comment by dahart | Hacker News Reader

Hey what does this item in the FAQ mean?

> Do files merged by Pijul always have the correct semantic? > No. Semantics depends on the particular language you’re using, and Pijul doesn’t know about them.

That makes it sounds like Pijul might sometimes merge two functionally correct versions of a file into an unfunctional, incorrect one? Is this referring to a problem git and other merge tools have as well, or is it unique to Pijul and a result of being so good at merging without conflicts that it sometimes lets through semantic conflicts?

View on HN

All version control tools have the same problem since AFAIK none of them care about the semantics of the program being version-controlled (except Unison).

For example, in file foo.js you export the function foo. Now, if you delete the function foo, while your colleague import it into bar.js, the resultant changes are consistent, but the program is now functionally broken.

monticello[0] cares about semantics too!

Tho I guess it cheats existing in an image-based world (I have never used it, it's just something stuck in my memory from many years ago).

[0] https://wiki.squeak.org/squeak/1287

Plsstic's diff tool is also centered around syntactic units of the programming language rather than stupidly scanning for line breaks, if it recognizes the language.

That still wouldn't mean that the merge is semantically correct.

This is why we test our builds using continuous integration. Only updates that compile and pass the tests should be published.

How does Pijul handle continuous integration? If there’s nothing interesting going on with that then I don’t see how the UX can be any different for publishing new versions.

Yes of course this can happen in git as well, as it doesn't know the semantics of the changes it is merging, it only knows about textual conflicts. But if a change applies cleanly it doesn't mean that it necessarily also works, because the other branch might've changed the program logic.

It doesn't happen very often, but it is still worth running integration tests after a merge even if both branches were passing tests on their own.

So in this scenario there's a general case and a special case.

The general case is where merging a patch makes the code invalid in some sense. This can range from a syntax error to a subtle bug. Version control systems don't prevent this, because they can't: in full generality, correctness is an opinion of the author.

The special case is where two patches each create a valid program, but applying both of them makes the program invalid. I think that's in the FAQ because pijul makes much of the fact that it has a sound theory of patches, as it should, that's a wonderful thing. But people commonly confuse soundness and validity, leading to questions like "so what you're saying is that a merge will never result in a borked program?".

IMHO that shouldn't be in the FAQ though, because it creates the impression you got, which is that Pijul is talking about something which might be possible in principle but which it doesn't happen to be capable of. It's just patiently explaining that Pijul can't do impossible things.

Reply on news.ycombinator.com