Andy Parkins <andyparkins@xxxxxxxxx> writes: > 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. - 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