Re: [PATCHv3 1/2] Make xdi_diff_outf interface for running xdiff_outf diffs

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 21, 2008, 05:24 UTC
Message-ID: <7vzln7j5yx.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080821033756.GC31114@lavos.net>

bdowning@lavos.net (Brian Downing) writes:

Show 12 quoted lines

> On Wed, Aug 13, 2008 at 11:18:22PM -0700, Junio C Hamano wrote:
>> Much nicer.  xdi_diff() is just a performance thing that only kicks in
>> when you are running -U0 diff, so it is unsurprising that you did not see
>> any test failures.
>
> Interesting point here.  In playing with trying to cache the diff hashes
> to speed up blame, I had to basically disable the xdi_diff tail trimming
> when building the hash the first time, because it needed to see the
> whole file.  In doing this, I discovered that just changing from
> xdi_diff to xdl_diff /does/ change the blame -M -C -C --incremental
> result for my test case.  (Unfortunately, my test case is proprietary
> code...)

Is the reason why you mention "incremental" specifically because you only tested incremental, or you get identical result in non-incremental mode?

If your material is repetitive, say you have lines "A A A B C A A A" in the parent blob and "A A A B A A A" in the child blob, and you are trying to pass blame on three line block "A A A" at the beginning of the child, we can pass blame to the three lines at the beginning part, or to the end part, without Linus's common tail trimming optimization. But there is no way it can match the end part with the optimization.

You cannot say one result is more correct than the other --- both are equally correct. Of course, you could argue that with such a highly repetitive material, it may be better to match closer ones, but it's a judgement call.