Re: [jgit-dev] "instable" diff algorithms lead to wrong merge results

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, Nov 24, 2010 at 4:23 PM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
>>
>> From what Junio explained to me, it sounds like the "lines of context"
>> rule used by C Git is sort of an accident.
>
> It was no accident. The merge code is all mine, and if you do not ask me
> about it, well, you can only guess what the intention was, Shawn.

Sorry, I was banging out an email off-the-cuff the other day to
Christian, I didn't want to bother cracking open git log to see who
mucked with or wrote the merge code, or when this particular feature
occurred.  It seemed like too much effort to simply point out to
Christian that the C implementation of merge uses a lines of context
rule.  And so does RCS, because I remember that from the dark days of
using CVS and even RCS.

Too many folks have contributed to C Git to always remember who wrote
what, when, or what they had done intentionally vs. what was simply an
accident.  I'm glad you are still lurking around here to set the
record straight where my own memory is incomplete or infallible.

> The idea was that the merge would be not only a 3-way merge, but that due
> to the setup of Git, we would know exactly that the base is really a base
> version from which two different lines of development started.
>
> So there is effectively 1 (or 0.5, depending on your interpretation) line
> overlap, since if boundaries touch, the diffs are evaluated as conflicting
> (unless some enterprisey person managed to slip changes to the core merge
> machinery by me ever since I wrote it).

That's an interesting approach.  Boundaries touching is sufficient?
No need for a higher value?

-- 
Shawn.