On Wed, Jan 30, 2002 at 06:18:11PM -0500, Rob Landley wrote:
> > And you just lost some useful information. The fact that so-and-so did
> > fix A and then did B is actually useful. It tells me that A didn't work
> > and B does. You think it's "crap" and by tossing it dooms all future
> > developers to rethink the A->B transition.
>
> <rant>
I'll see your rant and raise you a nickel.
> If developers can't ever make temporary changes to their tree which they do
> NOT intend to send to linus, they can't FUNCTION. (Except my not doing
> development in said tree.)
Of course they can do that. They get to decide what they push and
what they don't. I don't think you understand BK. What we are talking
about is the problem that the change has been committed to CVS, other
changes are built on top of it, and now Linus realizes that the change
was bad news. The problem is extracting stuff out of the middle which
has already been built upon for more stuff. How would you propose solving
that problem because that is the problem statement?
If someone sends Linus a patch, he checks into BK or CVS or whatever,
he then gets 5 other patches and applies them in BK/CVS, and THEN he
wants to take out the first patch, how would you suggest we do that?
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:29 EST