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