Thread (28 messages) flat view 28 messages, 3 authors, 2016-06-15

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

From: David Kågedal <hidden>
Date: 2016-06-15 22:43:34

16 sep 2007 kl. 09.28 skrev Catalin Marinas:
On 16/09/2007, Karl Hasselström [off-list ref] wrote:
quoted
On 2007-09-15 00:31:09 +0200, David Kågedal wrote:
quoted
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
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help