Re: [StGIT PATCH] Don't use patches/<branch>/current

From: Karl Hasselström <kha@treskal.com>
Date: May 17, 2007, 14:57 UTC
Message-ID: <20070517145724.GA905@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0705170543g4d8c7542p6b44a4e6fa54676a@mail.gmail.com>

On 2007-05-17 13:43:35 +0100, Catalin Marinas wrote:

Show 7 quoted lines

> I ran 'git repack -a -d' and 'git prune'. There are no other objects
> apart from the generated pack:
>
> $ du -sh .git
> 211M    .git
>
> And then repeatedly 'time stg series > /dev/null':

Hmm, it seems there is a problem then. :-(

> It got smaller after repacking but it is still bigger than yours.
> Maybe the reason is that I have 14 branches with various patches,
> some of them just for historical reasons but going back to 2.6.12.
> There are also several commits generated for the patch logs.

OK. That shouldn't matter, though, since that extra history shouldn't be examined anyway.

> The CPU is a P4 at 2.5GHz and the 'stg series' operation seems to be
> CPU bound rather than IO. I'm also using Python 2.3 on this PC and
> for this reason I changed 2 generator constructs (x for x in ...)
> with list comprehension (see the attached patch).

I don't think that's the problem, since those lists are both small.

The only possibility I can think of that might explain this is that some of your unapplied patches are attached to a place in the commit DAG that's far away from the branch head (e.g. you have rebased to some entirely different place since you last had them applied), so that "git-rev-list patch ^branch" outputs a large part of the commit DAG.

Could you put counters in unapplied_patches() and sort_applied_patches() to see how many lines each of them reads from git-rev-list? The expected number (if it had taken just a little time, like it did for me) is a small constant times the number of patches in both cases.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle