Re: Merge-Recursive Improvements

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2008, 19:21 UTC
Message-ID: <7v63wqgh5i.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <47B29EBF.7060607@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 16 quoted lines

> 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.