|From:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|To:||David Miller <davem-AT-davemloft.net>|
|Subject:||Re: Announce: Linux-next (Or Andrew's dream :-))|
|Date:||Tue, 12 Feb 2008 17:31:10 -0800 (PST)|
|Cc:||bfields-AT-fieldses.org, jeff-AT-garzik.org, linux-kernel-AT-vger.kernel.org, akpm-AT-linux-foundation.org, linville-AT-tuxdriver.com|
On Tue, 12 Feb 2008, David Miller wrote: > > > Put another way: think of the absolute *chaos* that would happen if I were > > to rebase instead of just merging. Every time I pull from you I'd > > invalidate your whole tree, and you'd have to re-generate. It gets > > unmaintainable very quickly. > > I actually wouldn't mind that, the first thing I do when sending a > pull request is I stop putting things into my tree and as soon as the > recipient pulls I wipe out my tree and clone a fresh copy of their's. You *really* don't see the problem here? > I really like that mode of operation. *YOU* like it, because it never generates any issues for *you*. You're the top in your heap, and the people above you don't do that insane thing, so you get all of the advantages, with none of the downsides. Of *course* you like it. But as people have pointed out, it generates issues for the people under you! If I did it, the people who now complain about networking would not just be a couple, it would be everybody. Nobody could depend on anything out there, because everything would have to rebase. You just don't see the problems, because the only person above you isn't crazy enough to do what you propose. You also don't do ten merges a day of subsystems you don't know. The importance of merging (rather, not screwing up history in general) becomes really obvious when things go tits-up. Then they go tits-up *without* screwing up the history of the trees that were hopefully tested individually. If you re-base things that others developed, you lose that. Imagine if I merged first Greg's tree (by rebasing), and then there was some fundamental thing that didn't cause a conflict, but just made something not work, when I rebased yours on top. Think about what happens. Now I've merged (say) 1500 networking-related commits by rebasing, but because I rebased on top of Greg's tree that I had also rebased, absolutely *none* of that has been tested in any shape of form. I'd not use most of the things I pulled, so I'd never see it, I'd just push out something that was very different from *both* trees I pulled, with no way to really blame the merge - because it doesn't even exist. So as a result, some *random* commit that was actually fine on its own has now become a bug, just because it was re-written. You don't see the problem here? Yes, this is the *crap* you do all the time. You don't see the problems as much, because you merge probably only about a tenth of the volume I merge, and you can keep track of the subsystem more. But even though you don't have nearly the same kinds of problems, people have complained about your process. So there's a real reason why we strive to *not* rewrite history. Rewriting history silently turns tested code into totally untested code, with absolutely no indication left to say that it now is untested. You can limit the damage by keeping it to a single subsystem and by serializing that subsystem by - for example - talking it over amonst yourself what order you do things in, and yes, most of the time rewriting doesn't hurt anything at all, but I guarantee you that it's a big mistake to do, and the mistake gets bigger the more _independent_ people you have involved. Linus
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds