Re: problem with git detecting proper renames

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

 




On Nov 29, 2007, at 1:27 PM, Linus Torvalds wrote:



On Thu, 29 Nov 2007, Kumar Gala wrote:

In the case of multiple identical matches can we look at the file name as a
possible heuristic?

We already do. But we only do the base-name part and check it for
exactness, since moving across directories is very common, and we
explicitly want to pick up files that have the same base name.

However, in your case, not only did you have the same content, you had the same basename too! So git considered your renames to be totally identical
wrt scoring with the current heuristics, and just picked one source at
random.

And the current heuristics don't even have any "if you already found a
rename, avoid picking the same one twice", so it would pick the *same*
source both times, which is why it looked like "two copies and one
delete".

This is why I'd like to have a real-life example. I can change the
heuristics, and I even know what are likely to be better heuristics, but I still want to actually see and play with an example so that when I send
Junio a patch, I can explain it and say I've tested it with something
real..

Ok, this is a real example from the u-boot tree. If you give me a little while I can point you at a kernel.org git tree that showed this issue.

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