Petr Rockai writes: > Yes, and i maintain that it is correct. Or you also maintain, that if > a merge tool cleanly merges following, you would never use it?
Yup. (Never is too strong, obviously if a project I pull from uses Darcs, I'm kinda stuck with it.) > In other words, you are mixing up different problems, one that textual > merge cannot ensure correct semantic merge I disagree. I think that "clean textual merge" is a non-goal. For example, the git "ours" merge gives a guaranteed clean textual merge, and furthermore is 100% certain to preserve semantic correctness. (That is, if the "ours" branch is semantically correct, then the merge will be too, because the definition of the "ours" merge is to copy the "ours" branch exactly, and ignore the other branches being merged.) Of course, in a three-way merge it's almost never what you want (ie, at a deeper level, it doesn't provide anything close to a semantically correct merge). So clean textual merge is a heuristic for the correct semantic merge. In situations where the heuristic is very risky, such as adjacent lines in code, a merge tool should flag the merge for humans to consider. > (and if you argue that a case, where clean textual merge causes > semantic mis-merge, is a bad thing, then you should never use > textual merge at all). Are you arguing that a semantic mis-merge is a good thing, as long as it results from a clean textual merge? In fact, I generally don't trust textual merges of patches that touch the same file. Since I have to review the diffs anyway, I prefer to use tools like ediff to do the merge by hand rather than review the merged code with diff. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
