Messages in this thread | | | Date | Sun, 30 Oct 2005 16:16:48 -0800 | From | "Randy.Dunlap" <> | Subject | Re: [git patches] 2.6.x libata updates |
| |
On Sun, 30 Oct 2005 17:59:39 -0600 Rob Landley wrote:
> On Sunday 30 October 2005 16:36, Linus Torvalds wrote: > > > > Is this a viable option? > > > > No. > > > > There is no "ordering" in a distributed environment. We have things > > happening in parallel, adn you can't really linearize the patches. > > To clarify my thinking: > > It doesn't matter what the ordering is, as long as A) the patches are > separated somehow, B) the resulting kernel from applying any initial subset > (patches 1-X in the series) has some reasonable chance to build and work. > > Any arbitrary order is theoretically fine for (A). Alphabetical by msgid or > sha1sum. Or the order they appear in the changelog. > > It's (B) that's the tricky bit, but not an insoluble problem. "The order > Linux imported them into his tree" might give that. > > > The closest you can get is "git bisect", which does the right thing. > > Ok, so we've already got an order, whatever order git bisect puts them in. > (It doesn't have to be stable between releases, just a snapshot in time of a > set of individual patches which, cumulatively applied,would have the same > effect as the big rc1->rc2 diffs we've been getting.) > > It doesn't sound like it would be _too_ hard to abuse the "git bisect" > mechanism to work out each possible bisection point between -rc1 and -rc1, > and if that can be done why can't it spit out the individual patches (with > descriptions) and cat them together? > > Why wouldn't this work?
Why isn't there a linus.git ordering? that can be made to work.
--- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |