Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: very slow cherry-pick'ing (old-2.6-bkcvs tree)

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:43:34

Erez Zadok [off-list ref] wrote:
Our group maintains Unionfs on the latest -rc kernel, but we also maintain
several backports going all the way to 2.6.9.  Once we complete the
development and testing of a feature/fix in -latest, we cherry-pick those
commits to older backports, and test those.  When I cherry-pick from -latest
to my 2.6.{22,21,20,19,18} repositories, it works reasonably fast.  But when
I cherry-pick to my 2.6.9 tree, it runs about 20 times slower!  Why?  Is
there anything I can do to inspect what's going on and perhaps speed up the
cherry-picking process?
I'm guessing its due to rename detection.

git-cherry-pick is implemented in terms of git-merge-recursive,
which always does rename detection when files are deleted or added.
This can take some considerable time if there's a lot of files that
have been added/deleted.

What would probably be faster would be to dump the patches in
question using git-format-patch and then apply them using git-am.
This bypasses the rename detection as it is using strictly a diff
and an apply.

-- 
Shawn.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help