Re: Mercurial 0.4b vs git patchbomb benchmark
- From
- Morgan Schweers <mschweers@gmail.com>
- Date
- Apr 29, 2005, 20:16 UTC
- Message-ID
- <b8464fde050429131677ae06d1@mail.gmail.com>
- In-Reply-To
- <200504291954.MAA27561@emf.net>
Greetings,
On 4/29/05, Tom Lord <lord@emf.net> wrote:
Show 12 quoted lines
> > > > 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