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:	Mon, 26 Oct 2009 17:15:39 -0700 (PDT)
From:	David Miller <>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

From: Steven Rostedt <>
Date: Mon, 26 Oct 2009 19:51:01 -0400

> On Mon, 2009-10-26 at 16:30 -0700, David Miller wrote:
>> From: Steven Rostedt <>
>> Date: Mon, 26 Oct 2009 19:26:28 -0400
>> > I think this is more of a failure in git than in the work flow we
>> > present.
>> Others (like me) will say you should have let that patch cook for a
>> while on the mailing list or in your tree before publishing, in order
>> to let those acks and tested-by replies come in.
>> That's how I handle this.
>> And I really don't buy the argument that you have to publish the
>> change in a GIT tree to get those ACKs and tested-by replies.
> The thing is, I do my changes with git.

So do I.

> I get something working and then commit it. Then I do more changes
> and commit that. I don't use quilt anymore for this.

And you can do this all day long if you like.

What you can't do is _PUBLISH_ this anywhere to a tree that people
also do development against _UNTIL_ you get those acks and tested-by
tags back from people.

Once your acks etc. come in, you can pop all of those pending patches
out of your tree, add the ack tags to the commit messages, then
reapply them.

Then you can push to your public tree, but no sooner.

It really is that simple.
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