Re: slow git-cherry-pick.

On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast [off-list ref] wrote:

Paweł Sikora [off-list ref] writes:

quoted

Umm, there's a gem here that the thread missed so far:

quoted

my git repo isn't very big[1] but it's checked out on the linear lvm
where random i/o generally hurts and strace shows that current git version
performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before

           ^^^^^^^^^

There's no reason why it should do the lstat() *twice* for every file.
But Paweł is right; the code path roughly goes like this:

int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
[...]
        res = sequencer_pick_revisions(&opts);

int sequencer_pick_revisions(struct replay_opts *opts)
{
[...]
        read_and_refresh_cache(opts);
[...]
        return pick_commits(todo_list, opts);
}

static int pick_commits(struct commit_list *todo_list, struct replay_opts *opts)
{
[...]
        read_and_refresh_cache(opts);


I'm too tired to dig further, but AFAICT it's just a rather obvious case
of duplication of effort.

That's something to optimize, but it's single commit picking,
sequencer_pick_revisions() should call single_pick() instead of
pick_commits().

The read+close on the whole checkout looks like there's problem with
refresh operation and git decides to read up and verify sha-1 by
content. Pawel, if you run "strace git update-index --refresh" twice,
does it still show 1 stat + 1 read for every entry on the second try?
-- 
Duy