On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote:
quoted text
> 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. 

If there was a "fundamental thing that didn't cause a conflict", then
the two trees in question probably didn't touch the same code, so would
probably merge cleanly, for the same reason that one rebased onto the
other cleanly.  But depending on what the "fundamental thing" was, the
merge might still introduce the same bug, right?

--b.
--
unsubscribe notice
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/