lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 Feb 2008 23:25:12 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linville@...driver.com
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists