[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0910271232200.31845@localhost.localdomain>
Date: Tue, 27 Oct 2009 12:42:45 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
cc: Stefan Richter <stefanr@...6.in-berlin.de>,
Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
Nicolas Pitre <nico@...xnic.net>,
"Luck, Tony" <tony.luck@...el.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"Luis R. Rodriguez" <mcgrof@...il.com>,
Jeff Garzik <jeff@...zik.org>,
Robert Richter <robert.richter@....com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jean Delvare <khali@...ux-fr.org>,
Sam Ravnborg <sam@...nborg.org>
Subject: Re: [RFC] to rebase or not to rebase on linux-next
On Tue, 27 Oct 2009, Steven Rostedt wrote:
>
> On Tue, 2009-10-27 at 12:06 -0700, Linus Torvalds wrote:
> > Don't lie about
> > getting an ack that you didn't get before you made that patch public.
>
> But how do you get your ack without making it public?
There's a difference between exposing your git tree to the public, and
showing your patches to others.
A public git tree is _not_ the place to ask for comments for patches. If
you haven't gotten Ack's, you have two choices:
- that commit should not show up in a tree that is marked for -next,
because it's still waiting for feedback and people to test it. It may
be in a _private_ git tree of course, but it's not "ready" yet.
- you are going to commit it regardless of acks or not, and you don't
care, and you shouldn't lie about it later.
Those are the two obvious choices. Adding ack's later, after it has
already been exported and tested in -next is kind of pointless, isn't it?
It's basically lying about how the patch came to be.
If you want Ack's from people, then send that patch around by email.
NOTE! If you know the people you want acks from are git users, then the
email can certainly be something like "look at so-and-so branch of my git
tree <here>". You can certainly use private git branches as a way to talk
to other developers about code you're not fully happy with yet, with the
clear understanding that you want acks and comments on it.
Put another way: there's a big conceptual difference between "public git
tree" and "private git branch that may well be available to others and
is meant for development". In git itself, Junio has the 'pu' branch that
is clearly marked as being rebased etc.
Linus
--
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/
Powered by blists - more mailing lists