lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 27 Oct 2009 12:42:45 -0700 (PDT)
From:	Linus Torvalds <>
To:	Steven Rostedt <>
cc:	Stefan Richter <>,
	Theodore Tso <>, Ingo Molnar <>,
	LKML <>,
	Nicolas Pitre <>,
	"Luck, Tony" <>,
	Stephen Rothwell <>,
	"Luis R. Rodriguez" <>,
	Jeff Garzik <>,
	Robert Richter <>,
	Dmitry Torokhov <>,
	Jean Delvare <>,
	Sam Ravnborg <>
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists