Re: 2.6.19 -mm merge plans

[Sean <seanlkml@sympatico.ca>]

On Mon, 25 Sep 2006 00:34:45 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> 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.

Well, you're absolutely right about native Git being more focused on
tracking the final product.  However, there are tools growing up around
Git that attempt to give similar (although completely integrated with
Git) functionality of Quilt.  One such tool is Stacked Git (StGit)
http://www.procode.org/stgit/.  Since i'm not actually a user myself,
I can't vouch for it, but it does have a responsive community around it
and seems to be providing what it set out to accomplish.

Sean