[webkit-reviews] review granted: [Bug 48040] prepare-ChangeLog is slow when using git : [Attachment 71389] Patch

[bugzilla-daemon at webkit.org]

David Kilzer (ddkilzer) <ddkilzer at webkit.org> has granted Adam Roben (aroben)
<aroben at apple.com>'s request for review:
Bug 48040: prepare-ChangeLog is slow when using git
https://bugs.webkit.org/show_bug.cgi?id=48040

Attachment 71389: Patch
https://bugs.webkit.org/attachment.cgi?id=71389&action=review

------- Additional Comments from David Kilzer (ddkilzer) <ddkilzer at webkit.org>
This describes the difference in behavior from the git-diff(1) man page:

--find-copies-harder
    For performance reasons, by default, -C option finds copies only if the
original file of the copy
    was modified in the same changeset. This flag makes the command inspect
unmodified files as
    candidates for the source of copy. This is a very expensive operation for
large projects, so use
    it with caution. Giving more than one -C option has the same effect.

-l<num>
    -M and -C options require O(n^2) processing time where n is the number of
potential rename/copy
    targets. This option prevents rename/copy detection from running if the
number of rename/copy
    targets exceeds the specified number.

Do you typically run prepare-ChangeLog with no arguments?  (I usually specify
top-level directories, but maybe that's because I'm compensating for this
behavior already.)

I guess it's okay to try this to see if it misjudges any files.  (If it does,
that may be an early warning sign that "git svn dcommit" won't do an "svn copy"
when it runs, which might be a good thing.)

BTW, the "-C -C -M" options were added by you in r24432/r24433 over 3 years
ago.  :)
<http://trac.webkit.org/changeset/24432>
<http://trac.webkit.org/changeset/24433>

r=me