Re: [StGit PATCH 00/13] Eliminate 'top' and 'bottom' files
- From
David Kågedal <davidk@lysator.liu.se>
- Date
- Sep 16, 2007, 10:28 UTC
- Message-ID
- <2060EB60-9404-429F-94D8-3739B06BB96E@lysator.liu.se>
- In-Reply-To
- <b0943d9e0709160028h41a67474g6b379a45c4c88432@mail.gmail.com>
16 sep 2007 kl. 09.28 skrev Catalin Marinas:
Show 15 quoted lines
> On 16/09/2007, Karl Hasselström <kha@treskal.com> wrote: >> On 2007-09-15 00:31:09 +0200, David Kågedal wrote: >> >>> The following series removes the 'bottom' and 'top' files for each >>> patch, and instead uses the commit objects to keep track of the >>> patches. >> >> Wonderful! Does this ensure that there's a bijection between patches >> and commits at _all_ times, or am I missing something? > > We should get rid of top.old and bottom.old as well. > > 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.
My refactoring of the push_patch function will conflict because of refactoring, but it doesn't change how the appliedness is used, so it should be pretty simple to resolve.
Or I could try to redo the patches so it only has the minimal changes to actually remove the top and bottom files.
Show 7 quoted lines
>> Hmm, wait, no. Right. We also have to create commits for those >> patches >> that don't have exactly one commit object. Not that there'll be many >> of them, but better not make assumptions ... > > 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.
I haven't seen any such case. Can uncommit create one? Or did it use to do that before? I added checks to detect it, and no test case caught it at least.
-- David Kågedal davidk@lysator.liu.se