Hi, On Mon, 28 Jul 2008, Miklos Vajna wrote: > Testing is done by creating a simple git-merge-theirs strategy which is > the opposite of ours. Using this in real merges is not recommended but > it's perfect for our testing needs. Note that what was asked for, and what Junio implemented before deciding that it would do more harm than good in git.git, is not the same as what you provide. Your -theirs is a strict opposite of -ours, i.e. the tree after the merge will be identical to the "merged" branch's tip's. The -theirs which was asked for (and which I truly think is insane) wanted to do a merge, and in case of merge conflicts take the "upstream" version _only of the conflicting hunks_. Just to make sure everyone grasps why this is bad: - there is not only a real chance, but a high probability that a merge conflict means that some related, unconflicting change relies on _one_ version of the conflicting hunk which might very well be "ours", and - since we have a _recursive_ merge, the notion of "upstream" is completely bogus when working on any merge that has more than one merge base. This merge would succeed, but actively be wrong. Just to make sure people do not have to ask for that version of "-theirs" again, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
