Re: [git patches] 2.6.x libata updates

[Rob Landley <rob@landley.net>]

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?

>   Linus

Rob