Re: StGIT: "stg new" vs "stg new --force"

From: Pavel Roskin <>
Date: 2006-01-19 11:49:09
On Wed, 2006-01-18 at 20:37 +0100, Yann Dirson wrote:
> > > It would even be useful sometimes to dispatch changes to a single file
> > > into several patches.  When they are distinct enough to be in
> > > different diff hunks, it is pretty easy to split an existing patch,
> > > but it could also be useful to only refresh a patch with specific diff
> > > hunks.  A possibility would be to add a filterdiff-like "-#<n>" flag,
> > > in addition to the above-suggested "refresh <file>" (and possibly only
> > > allow to specify a single file together with this flag).
> > 
> > I think if would be better to improve "stg fold" to work on arbitrary
> > patches.  This way, you prepare the patch in the editor (which would not
> > be harder than finding hunk numbers) and fold it into the patch of your
> > choice.  stg should check that the stack remains valid, possibly doing
> > trivial adjustments to the higher patches.  The current tree should not
> > be impacted.
> This sounds like a good idea as well (and I would use it on a near
> daily basis as well ;).  Obviously such a request can also fail,
> eg. when requesting to fold a change into a patch, where a subsequent
> patch modifies the same lines.

Definitely.  Hard cases should be handled by hand.

> But it would not be a replacement to selecting changes with a
> granularity finer than file-level, which is what I wanted to suggest.

Why?  Maybe you got confused by two meanings of the word "patch"?  I
think StGIT should use some other term, e.g. changeset.  I meant that
the diff file (e.g. made by "stg diff") could be edited and folded into
one of the StGIT patches (changesets).  Unless you want non-interactive
separation of the hunks, using an editor should be a reasonable

I believe StGIT should be primarily designed to be used interactively.
Your approach looks like a usability disaster to me.  The user is
supposed to find numbers of the hunks, although s/he is working on the
whole file (since it's "stg refresh").

My approach suggests that the user work with the diff from the
beginning, and separates the changes by looking at them.

Pavel Roskin

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at
Received on Thu Jan 19 11:51:13 2006

This archive was generated by hypermail 2.1.8 : 2006-01-19 11:51:21 EST