Re: [PATCH 1/1] Bypass expensive content comparsion during rename detection.

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

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> > Unfortunately we still have to at least initialize the sizes of the 
> > source and destination files even if the SHA1 values don't match. 
> > Failing to initialize the sizes causes a number of test cases to fail 
> > and start reporting different copy/rename behavior than was expected.
> 
> It has a wrong feel to it when you say we have to check the sizes first. 
> After all, we are heavily relying on the hashes being different, including 
> the case when the sizes are different. So, the order of the checks should 
> _not_ matter. I suspect that somewhere sha1_valid should be set to 0, but 
> isn't.

Yes.  :-)

I'll admit, I don't understand the diffcore rename code very well
so I'm treading around in code that I'm not used to.  I'm not sure
why the size member of diff_filespec needs to be initialized to get
rename and copy detection to work properly, but it apparently does.


My first version of the patch had the hash comparsion right after
we called diff_populate_filespec to get the size data.  But then
I realized that very often the sizes will be different and the
src->size != dst->size comparsion will tend to be true most of
the time, thus saving us a (relatively) expensive hash comparsion,
which we know must fail anyway if the sizes differed.

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