linux-kernel - Re: 2.6.19 -mm merge plans

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-next>] [day] [month] [year] [list]

Date:	Mon, 25 Sep 2006 00:34:45 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Sean <seanlkml@...patico.ca>
CC:	Russell King <rmk+lkml@....linux.org.uk>,
	Lennert Buytenhek <buytenh@...tstofly.org>,
	Linus Torvalds <torvalds@...l.org>,
	Dave Jones <davej@...hat.com>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	davidsen@....com, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19 -mm merge plans

Sean wrote:
> On Sun, 24 Sep 2006 10:20:10 +0100
> Russell King <rmk+lkml@....linux.org.uk> wrote:
> 
>> The point I'm making is that for some things, keeping the changes as
>> patches until they're ready is far easier, more worthwhile and flexible
>> than having them simmering in some git tree somewhere.
> 
> It's not really easier, just different.   Git allows you to make a 
> "topic branch" to keep separate items that need to bake before going
> upstream without being mixed in with all your other worked.
...
> Git _does_ make it easy and practical to do the same thing.

I'm not convinced. Certain workflows are more focused on how changes
change (sic) rather than on how the end product i.e. the sources change.
I am referring to reworking of patches during tests and reviews as well
as rewriting descriptions, collecting Acks and Sign-offs etc. while
maintaining a certain identity of the patch or series of patches.

But maybe I'm just not aware of how git may support this effectively.
Perhaps thusly: Let the young and wild times of life of a patch actually
result into many commits to a topic branch; collapse a lot of these
commits into one or few diffs for each review round; move to a new topic
branch for bigger reworks of the changeset; and finally collapse it into
one or few commits to a staging branch for submission? Sounds still more
like a job for patch-centered tools like quilt.
-- 
Stefan Richter
-=====-=-==- =--= ==---
http://arcgraph.de/sr/
-
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/