Re: [PATCH] diffcore-rename: favour identical basenames

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] diffcore-rename: favour identical basenames

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:17

Linus Torvalds [off-list ref] writes:
We'e also had things like

	arch/i386/kernel/pci-pc.c -> arch/i386/kernel/pci/common.c

so it's not always the ending of a file that is unchanged, but you still 
often have some "similarity" of the name (ie the "pci" substring is still 
common there).
This is not an example to draw very useful conclusions, is it?

The heuristics to say '-pc => common' is a more likely rename
than '-obscure-arch => common' heavily depends on human
intelligence in the context of a particular project, the kernel,
where there are rules such as "peripherals are tested most
widely on PC architectures, so assume that the vendors might
have tested their stuff only on PCs".

But I do agree that not limiting to basename has values.
Taking example from the "I cannot draw so here is a red big X",
it is quite possible that two red big X's are replaced with
properly rendered icons, while their format modified, like so:

    images/ok-button.gif => images/buttons/ok.png
    images/cancel-button.gif => images/buttons/cancel.png

This suggests that we might be able to look around to see what
other rename src/target candidate files there are, so that we
can figure out if there is a common pattern (i.e. in the above
example, "patsubst images/%-button.gif,images/buttons/%.png" is
what is going on).  If we find such a pattern, we can base the
assignment of "basename similarity bonus" on that pattern.

Re: [PATCH] diffcore-rename: favour identical basenames

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:17


On Thu, 21 Jun 2007, Junio C Hamano wrote:
This is not an example to draw very useful conclusions, is it?

The heuristics to say '-pc => common' is a more likely rename
than '-obscure-arch => common' heavily depends on human
intelligence in the context
Oh, absolutely.

I'm just saying that *if* you see two equally weighed content moves, if 
you then prefer the one that has more in common with the name, that's 
likely the right choice. 

In the actual example I gave, there was no ambiguity: the file contents 
were very obvious. But let's sat that you happened to have an example of 
two files with 100% identical content that moved, and you had the files

	-arch/i386/kernel/pci-pc.c
	-arch/alpha/kernel/pci-pc.c
	+arch/i386/kernel/pci/common.c
	+arch/alpha/kernel/pci/common.c

to match up, how would you do it? Again: they're all identical files: we 
can obviously agree that two files got renamed, but what is the pairing.

I'd suggest that if you do it by matching up the similarity of the 
filenames (not necessarily "exact same basename"), you'd actually catch 
it. In this case, they all have "pci" in them, but the "alpha" similarity 
would make you select the right one.

Similarly, in some other cases, the "pci" might be the thing they have in 
common, and might be the thing that decides that "oh, those two filenames 
look like they might be more of a better pair".

And yes, all of this would trigger only if the file data content match is 
non-conclusive. The file data is *more* important, but that doesn't mean 
that the file name similarity is *totally* unimportant either.

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help