>>> Samuel Lijin <sxlijin@xxxxxxxxx> schrieb am 03.05.2017 um 09:12 in Nachricht <CAJZjrdVZ7gTZvm=CcG7pUPWtXjsMsHgyMRiE8xoXm=bZ4j6FEQ@xxxxxxxxxxxxxx>: > On Mon, May 1, 2017 at 7:59 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Samuel Lijin <sxlijin@xxxxxxxxx> writes: >> >>> On Fri, Mar 31, 2017 at 10:52 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>>> It might not be a bad idea to teach "blame" not to pay attention to >>>> any path that is marked as "-diff" (e.g. binary files) when trying >>>> to see if remaining contents appeared by borrowing from them. We do >>>> not have that heuristics (yet). >>> >>> Could you elaborate on this? Do you mean to tell diffcore-rename to >>> ignore diff_filespec objects if they're binary? >> >> No and yes ;-). I do not think it is a good idea to unconditionally >> ignore binary in diffcore-rename. >> >> But when we know that the rename detection is called from inside >> blame.c, where by definition we would be digging line-oriented >> contents, there is no point checking if the contents we are looking >> for came from an existing binary file. > > A followup thought: perhaps it would make sense for blame.c rename > detection to only consider files with the same extension? As traditionally file type and file name extension had little to do with each other in UNIX, I thing that would not be a good solution (to assume the opposite). I also know that Git does not care too much about hierarchies also, but my idea was so find candidates "nearby", i.e. look in the subdirectories of the first level and in the parent directory; then, if needed, widen the radius of the search... Regards, Ulrich