Hi Michael, On Wed, Apr 17, 2013 at 11:55:04AM +0200, Michael Meeks <michael.meeks@suse.com> wrote:
On Tue, 2013-04-16 at 10:19 +0200, Miklos Vajna wrote:I tried that on a sample repo, so thanks for bringing this up. It seems the git rename detection is O(N^2), so the default number of renamed files is limited to avoid long merges.Presumably it would be possible to cache rename information trawled from the history at great cost, so a second time a cherry-pick is done, things are much harder ? (at least locally that is).
If we see that a git cherry-pick indeed takes a lot of time, and if the majority of the time is spent in rename detection, then I would look into some kind of caching, sure. IIRC rename detection works on two trees, though, so practically whatever you cache may be potentially reused next time you cherry-pick the same commit to the same branch, which is unlikely. :-) Miklos
Attachment:
signature.asc
Description: Digital signature