cherry-pick across renames [was: minutes of ESC call ...]

[Miklos Vajna]

Hi Michael,

On Wed, Apr 17, 2013 at 11:55:04AM +0200, Michael Meeks <michael.meeks at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130417/1310007f/attachment.pgp>