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

On 2007-05-17 21:51:19 +0100, Catalin Marinas wrote:

On 17/05/07, Karl Hasselström [off-list ref] wrote:

quoted

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 probably it, then. I'll need to come up with a clever scheme to
make that case cheap again.

That's the reason for the hide/unhide commands.

Ah.

Anyway, I'm not yet prepared to give up my current workflow.

I didn't intend to make that workflow painful, so don't despair yet --
there might be a way to make it work.

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.

I know.

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

The order of _all_ patches is kept in the "patchorder" file. This file
is consulted only when the relative order of two unapplied patches
need to be established. (Applied patches are sorted by the DAG, and
applied patches always precede unapplied patches.)

I would like to avoid keeping a record of known-to-be-unapplied
patches; while this is nowhere near as important as not keeping a
record of applied patches, it would still provide an opening for the
user to confuse StGIT.

But I believe I have a cunning plan ...

quoted

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.

Thanks for hanging in there.

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