Re: Resolving conflicts

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

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