Re: Rename detection at git log

From: Junio C Hamano <junkio@cox.net>
Date: Nov 20, 2006, 10:48 UTC
Message-ID: <7virha4cnm.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200611201022.10656.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 10 quoted lines

> On Monday 2006 November 20 10:07, Junio C Hamano wrote:
>
>> The real issue here is because the b/a on the command line
>> applies on the input-side, and does not act as the output
>> filter.  This comes from _very_ early design decision and if you
>> dig the list archive you will see Linus and I arguing about
>> diffcore-pathspec (which later died off).
>
> I don't think so; even without the b/a on the command line,
> git does not find copies made in this way...

I wrote the code and you contradict me ;-)?

Trust me, I know this area reasonably well, to the point that sometimes I wonder if there is a sane and cheap way to change the meaning of the pathspec to be an output filter and then quickly say "Nah" to myself.

If you say

	git diff --find-copies-harder HEAD^..HEAD -- fileB

in your example, it would give you the creation of fileB, not copy.

There are a few things we need to be careful about rename/copy.

 - Typically too small files are not treated as copies unless
   they are identical copies (does not apply to this case,
   luckily).

 - Renames are only picked up from files that were lost in the
   same change (i.e. "mv fileA fileB" creates fileB and loses
   fileA; fileB is checked if it is similar to fileA in the
   original).

 - Copies are only picked up from files that were changed in the
   same change (i.e. splitting major part of original file and
   moving it to somewhere else, while leaving a skelton in the
   original file).  "harder" is needed if the copy original was
   untouched, as you found out.

The last one is a compromise between performance and thoroughness, and the "harder" is one knob to tweak its behaviour.

In the kernel archive,

	git show -C ad2f931d

tells us that:

 - drivers/i2c/chips/Kconfig lost major part of it and only
   skeletal part of the original remains in it;

 - major part of it went to drivers/hwmon/Kconfig;

The story is similar to the Makefile next door.