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]

Date:	Thu, 14 Feb 2008 19:35:03 +0200
From:	Benny Halevy <bhalevy@...asas.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <bfields@...ldses.org> wrote:
> 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.

One idea that I thought about when debating rebase vs. merge (and it's
far far from being fully baked) is versioned commits.  The gist of it
is that patches are assigned an hash identifier like today when they are
first committed into the tree, but, and this is the main change: if they mutate,
e.g. by a rebase, or even git commit --amend, their version is bumped up rather
than SHA changed.

This way all versions of the commit would be accessible and addressable using
their respective SHA *and* version. I think that this can help keep
the tree's history in a more intuitive way (since the patches' base identifier
won't change, just its version number), and you get a bonus of seeing each
commit's history, who changed it, and what was the change.

Benny

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