Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Voltage Spike schrieb: >> Third, git doesn't appear to have any sense of context when performing a >> merge. Another contrived example which wouldn't be flagged as a merge >> conflict: >> >> ptr = malloc(len); // Added in HEAD. >> init(); // Included in merge-base. >> ptr = malloc(len); // Added in "merge". > > You seem to say that you want this to result in a merge conflict. > > I'm opposed to this: It means that you would mark a conflict if there is a > single unchanged line between the two changes that come from the merged > branches. So far it has happened for me much more frequently that such > merges were correct, and I should not be bothered with conflict markers. I > conciously prefer to pay the price that such a merge is incorrect on occasion. Actually I think we really should mark this as conflict. The tool should resolve only the most unquestionable cases and keep humans in the loop to validate the result if there is any uncertainty. Resolving the above example automatically without warning is most likely a problem waiting to happen. Such a merge being more often correct than not is not an argument for resolving them silently. It's rare mismerge cases that will bite you later, and we should really be careful, especially when a mismerge is less common. - 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
