linux-kernel - Re: [RFC] to rebase or not to rebase on linux-next

lists.openwall.net		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 linux-cve-announce 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]

Message-Id: <20091026.171539.06989895.davem@davemloft.net>
Date:	Mon, 26 Oct 2009 17:15:39 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rostedt@...dmis.org
Cc:	sam@...nborg.org, mingo@...e.hu, linux-kernel@...r.kernel.org,
	nico@...xnic.net, tony.luck@...el.com, sfr@...b.auug.org.au,
	mcgrof@...il.com, jeff@...zik.org, robert.richter@....com,
	dmitry.torokhov@...il.com, khali@...ux-fr.org,
	torvalds@...ux-foundation.org
Subject: Re: [RFC] to rebase or not to rebase on linux-next

From: Steven Rostedt <rostedt@...dmis.org>
Date: Mon, 26 Oct 2009 19:51:01 -0400

> On Mon, 2009-10-26 at 16:30 -0700, David Miller wrote:
>> From: Steven Rostedt <rostedt@...dmis.org>
>> 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 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/