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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
