[lkml]   [2005]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-10-31 01:19    [W:0.067 / U:5.596 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site