Re: 2.6.19 -mm merge plans

[Stefan Richter]

Sean wrote:
> On Sun, 24 Sep 2006 10:20:10 +0100
> Russell King <rmk+lkml@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/