Re: Mercurial 0.4b vs git patchbomb benchmark

[Morgan Schweers <mschweers@gmail.com>]

Greetings,

On 4/29/05, Tom Lord <lord@emf.net> wrote:
> 
> 
>   > Call me a naive git, but seems to me the "git way" is a little
>   > different. It's tree-based rather than diff-based, and doesn't involve
>   > passing diffs around, right?
> 
> Isn't that a significant part of what I said?  Go back and read more
> carefully, is my suggestion.
> 
>   > Or am I missing something?
> 
> Very much so.

It doesn't appear that he is.  You appeared to predicate your argument
on the 'auditor' believing a diff looks good, but getting a tree
instead, that might not reflect the diff.

Instead, in the git-world, the auditor actually gets a tree, and
produces the diff themselves, and then decides whether the diff looks
good enough to keep.

The argument about the high velocity of git-transfers causing the
inability to check doesn't appear to apply here, because the
distributed development environment of Linux says that the
'gatekeepers' ARE in fact validating the changes from people in their
area of expertise are good (or are relying on sub-gatekeepers), and
then Linus is trusting them completely.

This seems like the methodology that has been used up until now via bk
previously.  Git doesn't change that, and in fact supports that method
of development.

Your further suggestion that Linus could be replaced by a
patch-manager, in that case, got a chuckle from me at least, but the
more serious point is that Linus is necessary as the arbiter of who
actually receives the absolute trust of a gatekeeper.  He is, in
effect, a meta-gatekeeper.

> -t

In reading this conversation, it seems you're looking for a more
absolute standard of trust than the kernel developers are working
with.  I believe this is an example of 'good enough' process being
accepted, versus 'perfect' process.

--  Morgan Schweers