On 2007-05-17 21:51:19 +0100, Catalin Marinas wrote:
> On 17/05/07, Karl Hasselström <kha@xxxxxxxxxxx> 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 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 ...
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
