Hi Michael, On Wed, Apr 17, 2013 at 11:55:04AM +0200, Michael Meeks <michael.me...@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
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
