On 15 February 2016 at 09:03, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Gonçalves Assis <felipeg.assis@xxxxxxxxx> writes: > >> However, if you do find this approach acceptable/desirable >> (rename-threshold > 100%), I can work on the issues pointed out and >> propose a proper patch. > > The caller asks diffcore-rename to detect rename, and the algorithm > compares things to come up with a similarity score and match things > up. And you add an option to the rename detection logic to forbid > finding any? > > To be bluntly honest, the approach sounds like a crazy talk. > > If your goal is not to allow rename detection at all, why not teach > the caller of the diff machinery not to even ask for rename > detection at all? merge-recursive.c has a helper function called > get_renames(), and it calls into the diff machinery passing > DIFF_DETECT_RENAME option. As a dirty hack, I think you would > achieve your desired result if you stop passing that option there. > > I called that a "dirty hack", because for the purpose of not > allowing rename detection inside merge-recursive, I think an even > better thing to do is to teach the get_renames() helper to report to > its caller, under your new option, "I found no renames at all" > without doing anything. > > It might be just a simple matter of teaching its callers (there > probably are two of them, one between the common ancestor and our > branch and the other between the common ancestor and their branch) > not call the get_renames() helper at all under your new option, but > I didn't check these callers closely. Thanks for all the ideas. In order to have something concrete to discuss, I submitted the patch "merge-recursive: option to disable renames". Is that what you had in mind? I would be happy to receive comments and either improve it or try something else. Felipe -- 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