Re: [StGit PATCH 00/13] Eliminate 'top' and 'bottom' files

From: Karl Hasselström <kha@treskal.com>
Date: Sep 17, 2007, 08:17 UTC
Message-ID: <20070917081702.GB8657@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0709160028h41a67474g6b379a45c4c88432@mail.gmail.com>

On 2007-09-16 08:28:53 +0100, Catalin Marinas wrote:

> We should get rid of top.old and bottom.old as well.

Yeah, I guess that data could be computed from the patch log?

> My question - does this conflict with the DAG patches in any way? I
> intend to include the them at some point, once I get a chance to
> test the performance penalty with a big tree like the Linux kernel.

I haven't been able to get rid of all the expensive DAG walking, so I've been considering a different approach: continue using the current applied and unapplied files if the existing HEAD == top patch check passes, and letting the assimilate command do a full DAG walk to regenerate those files. (And by "full DAG walk", I mean walking from HEAD down to the first commit with parents != 1; the patches we see are applied (in the order we see them), and the rest are unapplied.)

> Is there any patch which consists of more than one commit? Maybe
> only uncommit could generate one but I think we put some tests in
> place.

Uncommit does not generate such patches, unless I've made a thinko; I don't approve of them. But I always assumed they could exist, since the code (at least in places) seems careful to not assume anything about the number of commits between top and bottom.

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