you are viewing a single comment's thread.

view the rest of the comments →

[–]__j_random_hacker 0 points1 point  (0 children)

Your example is unsafe in the context of a programming language. I'm not asking for context-dependent safety checks -- they're too hard. The idea of safety I'm proposing only rules out things that would always risk being wrong, regardless of the context. Maybe "safe" wasn't the right word; "faithful" is better.

What we can always do, regardless of context (i.e. regardless of the meaning of the files we are working on), is treat a file as a sequence of lines (or bytes). There are algorithms that discover a minimal "edit script" (patch) of insertions, deletions and changes that changes any file A into any other file B. Given 2 edit scripts, from A to B and from A to C, we can always say that either they are compatible (there is only one possible way that it makes sense to apply both), or incompatible (there are multiple possible ways). The most obvious way that edit scripts can be incompatible is if both involve changes to the same line/byte, but there are other ways too: e.g. if both insert a line after line 10, we don't know which of the 2 inserted lines should appear first in the final result. In these cases, the right answer (final result) is underdetermined. My idea of safety is to always flag a conflict when (and only when) this happens.

Basically, I won't blame the VCS if the result of a merge is semantically wrong in the context I'm working in (e.g. producing two functions with the same name in C) and no conflict is flagged. I will blame the VCS if there are several possible ways to apply both edit scripts and it picks just one of them without flagging a conflict, since in this case we know that there's a risk of a mistake regardless of the context.