On Wed, Jan 30, 2002 at 02:17:05PM -0800, Linus Torvalds wrote:
> The way BK works now, if we call the quick-and-dirty fix "A", and the real
> fix "B", the developer has a really hard time just sending "B" to me. He'd
> have to re-clone an earlier BK tree, re-do B in that tree, and then send
> me the second version.
>
> I'm suggesting that he just send me B, and get rid of his tree. There are
> no dependencies on A, and I do not want _crap_ in my tree just because A
> was a temporary state for him.
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.
There is a reason that commercial companies guard their revision history
and fight like mad to preserve it. It contains useful information,
even the bad stuff is useful.
Some stuff may be so bad that it shouldn't ever get in the tree, but you
don't accept anything at all from those people in general. If Al Viro
takes one pass at a problem and it works well enough that it gets in
the tree, and then later does a pass two that cleans it up, I can learn
from that. That's very useful information, his brain frequently shines
a light in a dark corner but I'd miss a lot of that without the history.
Your approach is constantly dropping useful information on the floor.
It may not be useful to you but it's useful to virtually everyone
else. Saving that information will increase the quality and reduce
the quantity of the patches you get.
-- --- 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:26 EST