16 sep 2007 kl. 09.28 skrev Catalin Marinas:

quoted text
> 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.

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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html