Thread (13 messages) flat view 13 messages, 4 authors, 2016-06-15

Re: problem with git detecting proper renames

From: Kumar Gala <hidden>
Date: 2016-06-15 22:43:55

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

On Thu, 29 Nov 2007, Kumar Gala wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help