From: Steffen Prohaska Date: Wed, 13 Feb 2008 08:17:45 GMT Subject: Re: Merge-Recursive Improvements Message-ID: In-Reply-To: <47B29EBF.7060607@viscovery.net> On Feb 13, 2008, at 8:39 AM, Johannes Sixt wrote: > 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. > > You also need to draw a border line: a single unchanged line > between the > changes? Or better also conflict at 2 lines? Or 3? Maybe git could try various numbers and print a certainty measure that tells the user how far appart non-conflicting changes are. If changes are near git would print a low certainty and the user could decide to review the merge in more detail than he would usually do. Steffen