From: Linus Torvalds <torvalds@linux-foundation.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Harvey Harrison <harvey.harrison@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <randy.dunlap@oracle.com>
Subject: Re: [PATCH] mfd: kconfig exposing unbuildable driver
Date: Tue, 22 Apr 2008 14:47:07 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0804221443140.2779@woody.linux-foundation.org> (raw)
In-Reply-To: <20080422213621.GC21435@flint.arm.linux.org.uk>
On Tue, 22 Apr 2008, Russell King wrote:
>
> To be really frank, I'm beginning to wonder whether using git is such
> a good idea - at least if I was sending you a stream of patches then
> all I'd needed to have done was forward you the relevant patches as
> fixes to the previous set - and I wouldn't care whether you'd applied
> the previous set at that point.
>
> But with git, it has to be known what you're doing at your end before
> I can make a decision about how to fix issues at my end.
I really don't see what you are talking about, and nobody else has that
problem.
With patches, once you send them, they are sent, and you can't fix it.
With git, once you send my the "please pull", it's sent, and you can't fix
it.
And with either, you can update the queue later. I don't understand AT ALL
why you think they are different.
In fact, if anything, git trees are a lot more flexible. With git, what
you can do is fix up the tree at any time, and send me an email saying
"ok, if you already pulled it's too late, but if you didn't, the tree is
now fixed". That you can't do with patches, because once you've sent them
out they are out of your control.
But with both git and patches you can *always* just append on top of the
previous set. Just send me a new set of patches (with git, that obviously
means just sending me a new pull-request with updated information).
This is what everybody else does, it's not even unusual.
Linus
next prev parent reply other threads:[~2008-04-22 21:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 20:25 Harvey Harrison
2008-04-22 20:33 ` Russell King
2008-04-22 20:38 ` Randy.Dunlap
2008-04-22 20:45 ` Russell King
2008-04-22 20:47 ` Randy.Dunlap
2008-04-22 21:01 ` Russell King
2008-04-22 21:06 ` Randy Dunlap
2008-04-23 6:02 ` Andrew Morton
2008-04-22 21:05 ` Linus Torvalds
2008-04-22 21:36 ` Russell King
2008-04-22 21:47 ` Linus Torvalds [this message]
2008-04-23 20:14 ` pHilipp Zabel
2008-04-23 20:02 ` pHilipp Zabel
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=alpine.LFD.1.10.0804221443140.2779@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=harvey.harrison@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=rmk+lkml@arm.linux.org.uk \
/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®