CODEWITHSUNDEEP
gitgit-cherry
Arafangion
Arafangion

Reputation: 11950

Why is git cherry so astonishingly slow?

Given a repository structure of:

o-o-o-o-o-<several hundreds of commits>-o-o-C-o-o master
                                           /
                                          c (files moved to a subdirectory)
                                         /
a-a-a-<several tens of commits>-a-a-a-a-A-b-b-b-b tools

This is a multi-rooted repository, all the commits on the 'master' line indicated there have the first-parent being on that branch, and likewise, all the commits on 'tools' have their first parents following the tools branch.

The commit 'c' was done to allow the merge commit, 'C', to be trivial, so that the layout matches that of master.

Why does 'git cherry -v master tools take so long?

EDIT:

My local testing were referring to the wrong branch (I used the wrong name), however, it remains that git cherry is astonishingly slow.

Upvotes: 2

Views: 729

Answers (1)

TheCodeArtist
TheCodeArtist

Reputation: 22497

The git cherry command starts the comparision from the fork-point

$ git cherry -v tools master

           __*__*__*__*__> <tools>
          /
fork-point
          \__+__+__-__+__+__-__+__> <master>

We can avoid this by specifying a <limit> parameter to git cherry as follows

$ git cherry -v tools master <limit>

           __*__*__*__*__> <tools>
          /
fork-point
          \__*__*__<limit>__-__+__> <master>

Now all the commits along the branch up to and including are ignored; thus enabling the git cherry command to finish faster.

Why?

Going through the man page of git cherry we can note the following :

Because git cherry compares the changeset rather than the commit id (sha1), you can use git cherry to find out if a commit you made locally has been applied under a different commit id. For example, this will happen if you’re feeding patches via email rather than pushing or pulling commits directly.

Essentially this means that git cherry is NOT simply comparing the hashes of the commit-ids, but the entire changesets/diffs/commits. This is the main reason for the seemingly large amount of time taken (compared to other similar git commands).

Upvotes: 2

Related Questions