Bug 48040 – prepare-ChangeLog is slow when using git

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Adam Roben (:aroben)]

prepare-ChangeLog is slow when using git

[Adam Roben (:aroben)]

Created attachment 71389 [details]
Patch

[David Kilzer (:ddkilzer)]

Comment on attachment 71389 [details]
Patch

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

[Adam Roben (:aroben)]

(In reply to comment #2)
> (From update of attachment 71389 [details])
> 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 usually specify top-level directories, too. But even when doing that prepare-ChangeLog is pretty slow on Windows. This patch noticeably speeds it up.

> 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.)

I actually had one commit where this change made prepare-ChangeLog *better* at detecting moves. The patch renamed a lot of files from *Win.cpp to *.win.cpp. It's possible there will be cases where this makes things worse, though.

I noticed that resolve-ChangeLogs also passes -C -C -M. Maybe it should change, too?

Thanks for reviewing!

[Adam Roben (:aroben)]

Committed r70246: <http://trac.webkit.org/changeset/70246>

[Eric Seidel (no email)]

Nice.

[Csaba Osztrogonác]

Comment on attachment 71389 [details]
Patch

remove r+, because it was landed

[Adam Roben (:aroben)]

Committed r70246: <http://trac.webkit.org/changeset/70246>