Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.