16 sep 2007 kl. 09.28 skrev Catalin Marinas:
On 16/09/2007, Karl Hasselström <kha@xxxxxxxxxxx> 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.
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@xxxxxxxxxxxxxx
-
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
