From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jiri Kosina <jkosina@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [GIT PATCH] HID and USB HID update for 2.6.21-rc2
Date: Wed, 28 Feb 2007 10:20:08 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0702281013190.12485@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702281837200.4255@jikos.suse.cz>
On Wed, 28 Feb 2007, Jiri Kosina wrote:
> On Wed, 28 Feb 2007, Linus Torvalds wrote:
>
> > There is no excuse for putting a large array in a header file and
> > including it millions of times. Or even just twice. The point of a
> > header file is to *declare* things, not to have big data structures in.
>
> The point was that noone else than hid/hid-core.c would ever be going to
> include this header with blacklist.
So:
- clearly other people *do* include it.
- if no-one else incldues it WHY HAVE IT SEPARATE!
- if you want to have it separate for other reasons, YOU MAKE IT A .c
FILE, SINCE IT'S CLEARLY NOT A HEADERFILE!
In other words, there is *zero* excuse for that braindamage.
> But OK, I will leave it in there.
No. You need to realize just WHY it was wrong. Not just an "But OK".
Because if you don't see why I'm complaining, I can't pull from you. You
can send me patches, but for me to pull a git patch from you, I need to
know that you know what you're doing, and I need to be able to trust
things *without* then having to go and check every individual change by
hand.
If I have to check changes like this by hand, I want you to send patches
to the mailing list, so that other people can help me filter it out. It
really is that simple, and that fundamental. It's about code flow, and
it's about the fact that there's no way I can look at every change and vet
it for being sane.
I simply *cannot* do git-to-git merges with people I can't trust to have
good enough judgement that I don't need to do the micromanagement and
check everything myself. I can't afford to. I don't have the bandwidth,
but I also simply don't have the interest in micro-managing.
So people I do git merges with need to show that they have good taste and
skills, otherwise it needs to be done as open patches where *other* people
with good taste and skills can help me.
Linus
next prev parent reply other threads:[~2007-02-28 18:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 10:19 Jiri Kosina
2007-02-28 17:09 ` Linus Torvalds
2007-02-28 17:25 ` Jiri Kosina
2007-02-28 17:34 ` Linus Torvalds
2007-02-28 17:41 ` Jiri Kosina
2007-02-28 18:20 ` Linus Torvalds [this message]
2007-02-28 18:28 ` Linus Torvalds
2007-02-28 18:33 ` Randy Dunlap
2007-02-28 18:29 ` Jiri Kosina
2007-02-28 18:39 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0702281013190.12485@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®