Re: Resolving conflicts

From: Junio C Hamano <junkio@cox.net>
Date: Dec 2, 2006, 07:55 UTC
Message-ID: <7vejri20mf.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0612012018490.3476@woody.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 9 quoted lines

> [ Tangentially related.. ]
>
> On Thu, 30 Nov 2006, Wink Saville wrote:
>> 
>> Earlier had a problem with git wanting merge but didn't have it and
>> couldn't figure out which package it was in Ubuntu:( So I symlinked merge
>> to kdiff3 which worked at the time:
>
> Btw, what's the status of the xdl_merge() thing in "pu"?

I am *BEHIND*. There are too many distractions these days (read: day job) and I haven't touched git in any significant ways for the last several days.

I haven't looked at the code any further than minimally checking its external interface to be able to interface it with merge-recursive and no more. Namely:

 - I haven't read the algorithm to judge its correctness;

 - I haven't looked for leaks;

 - I haven't used the resulting merge-recursive in any real
   merge; some of our tests do rely on a correctly working
   merge-recursive, so it is not like the algorithm is always
   emitting "boo ha ha" and returning no conflicts ;-).

 - I haven't benched it to see how much performance is gained
   by bypassing an extra fork+exec.

Among the four patches Johannes sent out to the list and Davide, one was already in his original patch I have in 'pu', another makes the same return value change I did myself when interfacing the code with merge-recursive. I have queued the remaining two in 'pu', so there should be nothing missing.

One of them is marked as "fix off by one error" but it was about more than off by one (the code walks two arrays using one index for each, but the original code incorrectly used the same index to access both arrays at one point, which was also fixed). I did mind the lack of explanation and wanted to reword the log message, but as I said, I haven't read the algorithm to understand what the code is doing enough, so I cannot write anything useful there yet X-<, which is one of the reasons why it is still queued in 'pu'.