> Having history browsers draw fancy lines is fine but I see nothing wrong > with them extracting this from the free-form part of the commit message. > For informative purposes, we don't shy away from heuristics anyway, c.f. > our renames detection (heck, we are even brave enough to use that for > merges). ... and it works only because false positives (which make the merge actively wrong) are extremely rare. If there is the occasional false negative, well, it just makes merges more complicated and screws up visualization a bit, so you live with it. Move/copy detection almost always worked for me, but there are two cases where it didn't: 1) empty files. Each of them is marked as copied from a seemingly-picked-at-random one. 2) renaming a Gtk+ class. You rename it (e.g. from gtkclassnamea.c to gtkclassnameb.c) and at the same time do s/GtkClassNameA/GtkClassNameB/ s/GTK_CLASS_NAME_A(?:\>|?=_)/GTK_CLASS_NAME_B/ s/gtk_class_name_a(?:\>|?=_)/gtk_class_name_b/ and reindent everything. Guaranteed to have a similarity index around 30-40%, not more. I don't care much about it, but face it, it is *not* perfect. Paolo -- 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
