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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



bdowning@xxxxxxxxx (Brian Downing) writes:

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


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux