linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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]

Message-ID: <20080213175212.GB13462@fieldses.org>
Date:	Wed, 13 Feb 2008 12:52: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 09:43:10PM -0800, Linus Torvalds wrote:
> So just the fact that the right commit gets blamed when somebody does a 
> "git bisect" is I think a big issue. It's just fundamentally more fair to 
> everybody. And it means that the people who push their work to me can 
> really choose to stand behind it, knowing that whatever happens, their 
> work won't get diluted by bad luck or others' incompetence.
> 
> And no, maybe most people don't feel things like that matters. But I do 
> think it's important.

The obvious advantage to rebasing in this case is that the blame
(misplaced though it may be), at least lands on a commit that made a
single small change, likely making the problem easier to diagnose.

(As opposed to the case of a large merge, where all you may know is that
somewhere in the hundreds of commits done on one side of the merge there
was a conflict with the hundreds of commits on the other side.)

I think a lot of people would see rebasing as an acceptable tradeof that
gives up a small amount of accuracy in assigning blame to individuals in
return for a large increase in ability to debug problems.

I suppose one response to that would be that it's important that people
learn how to work in parallel, that failures to do so are particularly
important failures in the process, and that it's therefore worth it to
make sure that such failures are always identified specifically as merge
failures.

It would be nice if merges, like patches, were broken up into somewhat
smaller units.  There's an understandable desire to wait to the last
minute to actually commit to one's commits, but a willingness to do so a
little earlier might avoid some of the problems that seem to come from
having a lot of large merges happen all at once.

--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/