Hello everyone,

 I have two git repositories: one is the origin of the other. However no
 merging is being done as the projects in the repositories quite differ
 but still use the same core. So to propagate changes I cherry-pick
 those which are useful from one repository to another.

 however 'git cherry-pick' has lately started to last almost forever:

 $ time git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618
 Finished one cherry-pick.
 Created commit 7caef83: - removed some superfluous newlines
 2 files changed, 0 insertions(+), 2 deletions(-)
 git cherry-pick b42b77e66a83f1298d9900a9bb1078b9b42e8618  282.97s user 34.69s system 100% cpu 5:17.63 total

 Both repositories have approximately 16k commits and their forking
 point (merge base) is 250 to 490 commits far away. 'git gc' (even
 --prune) has been run.

 What can I do to make the 'git cherry-pick' instant again?

        Thank you,

 P.S.: I'm using git-1.6.0.1.
-- 
		Michal Vitecek		(fuf@mageo.cz)
--

[ message continues ]

Can you define "lately"?  Is it a function of your git version, or is it a

When talking about cherry-pick, the size of the history (unless the
repository has too many objects and badly packed) does not matter; the
operation is purely about your current state, the cherry-picked commit
itself, and the parent commit of the cherry-picked one.

Taking 5 minutes to cherry-pick a change to only two paths, one line
deletion each, is plain ridiculous, but if the tree state of cherry-picked
commit and the tree state of the target is vastly different (e.g. almost
no common pathnames), the behaviour is certainly understandable.  Ancient
git used straight three-way merge for cherry-pick, but recent ones use
more expensive "recursive-merge", which tries to detect renames.  If the
states of trees are very dissimilar, you can end up wasting a lot of time.

    $ H=$(git rev-parse 7caef83^) ;# the commit before cherry-pick
    $ C=b42b77e6 ;# the cherry-picked one

cherry-pick operation roughly runs these two diffs:

    $ time git diff --shortstat -M $H $C
    $ time git diff --shortstat -M $H $C^1

and uses the result to perform its work.  Can you clock these?

If you rarely have renames, it may be much more efficient to run "git
format-patch -1 --stdout $C | git am -3" instead of cherry-pick.
--

[ message continues ]

Hello,


 It's a function a cherry-picking some commits - afterwards
 cherry-picking crawls. One of the commits removes a number of files

 I too thought so but after cherry-picking starting taking so long I

 $ time git diff --shortstat -M $H $C
 2 files changed, 0 insertions(+), 2 deletions(-)

 $ time git diff --shortstat -M $H $C\^1

 Turning off renames detection in diff (via 'git config --add diff.renames
 false') helped and 'git cherry-pick' is instant now.

 Maybe my repositories are "strange" in some way. I would be more than
 happy to provide more information if needed.

        Thank you,
-- 
		Michal Vitecek		(fuf@mageo.cz)
--

[ message continues ]