> Having history browsers draw fancy lines is fine but I see nothing wrong
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html