lkml.org 
[lkml]   [2005]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [git patches] 2.6.x libata updates
Date
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
-
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/

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