From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Thu, 17 May 2007 20:51:19 GMT
Subject: Re: [StGIT PATCH] Don't use patches/<branch>/current
Message-ID: <b0943d9e0705171351j1a86a4f4ge0283c522a351645@mail.gmail.com>
In-Reply-To: <20070517145724.GA905@diana.vm.bytemark.co.uk>

On 17/05/07, Karl Hasselström <kha@treskal.com> wrote:
> 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.

That's probably the case. I have patches that I haven't rebased for
months but I keep them in case they might be needed in the future.
That's the reason for the hide/unhide commands. Anyway, I'm not yet
prepared to give up my current workflow.

I haven't tried to understand your patch yet but the unapplied patches
will never be in a linear DAG similar to the applied patches. Because
of this, we need to keep their order in a file anyway and we might not
need to run git-rev-list (BTW, how do you preserve the unapplied
patches order with the DAG implementation?).

> 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.

I'll do this tomorrow to confirm but that's probably the cause of the slow-down.

-- 
Catalin