You *really* don't see the problem here?
*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
--
