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

bdowning@lavos.net (Brian Downing) writes:

On Wed, Aug 13, 2008 at 11:18:22PM -0700, Junio C Hamano wrote:

quoted

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.

On Wed, Aug 20, 2008 at 10:24:22PM -0700, Junio C Hamano wrote:

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

I've only tested incremental at this point.

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.

Okay, that makes sense.  Thanks.

-bcd